Parceque des fois la sauvegarde cohérente est liée à plusieurs machines.
En restauration il y a grosso modo trois possibilités suite à un plantage :
a) On veut ramener un fichier ou un ensemble de fichiers dans un état antérieur (par exemple avant qu'ils ne soient écrasés ou mal écrits)
b) On veut ramener un serveur dans un état antérieur (par exemple avant une mise à jour foireuse)
c) On veut ramener un système dans un état antérieur (par exemple une appli et sa base de données avant un gros traitement qui a mal tourné)
En créant une branche par sauvegarde (par exemple avec la date de la sauvegarde dans la branche), il ets très facile en lisant les commits de la branche de voir si toutes les sauvegardes se sont bien passées ce jour là, si il y a eu besoin de relancer des sauvegardes à la main, si l'opérateur est intervenu etc.
Et ça, ça aide grandement quand on doit faire une restauration de type b) ou c).
En plus ca permet aussi facilement de faire un clone à une date précise pour garder des sauvegardes intégrales de l'ensemble du système.
Ben, git bisect.
Ca ca marche si je sais déjà à quel jour j'ai un fichier ou une base non corrompue. Si je cherche la sauvegarde dans laquelle tel ou tel fichier de conf fait plus de 40 octets je suis reparti en rebase à gogo.
[^] # Re: git push
Posté par Kaane . En réponse au sondage Quel logiciel libre pour vos sauvegardes ?. Évalué à 1.
Pourquoi ferait-on ça ?
Parceque des fois la sauvegarde cohérente est liée à plusieurs machines.
En restauration il y a grosso modo trois possibilités suite à un plantage :
a) On veut ramener un fichier ou un ensemble de fichiers dans un état antérieur (par exemple avant qu'ils ne soient écrasés ou mal écrits)
b) On veut ramener un serveur dans un état antérieur (par exemple avant une mise à jour foireuse)
c) On veut ramener un système dans un état antérieur (par exemple une appli et sa base de données avant un gros traitement qui a mal tourné)
En créant une branche par sauvegarde (par exemple avec la date de la sauvegarde dans la branche), il ets très facile en lisant les commits de la branche de voir si toutes les sauvegardes se sont bien passées ce jour là, si il y a eu besoin de relancer des sauvegardes à la main, si l'opérateur est intervenu etc.
Et ça, ça aide grandement quand on doit faire une restauration de type b) ou c).
En plus ca permet aussi facilement de faire un clone à une date précise pour garder des sauvegardes intégrales de l'ensemble du système.
Ben, git bisect.
Ca ca marche si je sais déjà à quel jour j'ai un fichier ou une base non corrompue. Si je cherche la sauvegarde dans laquelle tel ou tel fichier de conf fait plus de 40 octets je suis reparti en rebase à gogo.