Re: Avec le sujet c'est mieux : Rsync et le système de fichiers qui va bien
Salut Patrice,
phep a écrit :
> Oui, mais c'est aussi l'intérêt ! On n'a pas à craindre qu'une
> corruption d'un diff fiche par terre l'ensemble des versions d'un
> fichier.
Ah... l'idéal inatteignable de la sauvegarde : historisé, rapide,
compact, robuste et chiffré. Je crains qu'on ne puisse pas tout avoir.
Il faut faire des choix qui dépendent des priorités et des
contraintes. :)
Pour ma part, mes exigences principales sont :
- Historiser les sauvegardes sur une période confortable (au boulot, un
an glissant, à la maison... je n'ai encore rien supprimé depuis que
j'utilise rdiff-backup).
- Minimiser les données transférées (pour cause de sauvegarde distante
et de débit montant qui plafonne à 110 ko/s). À ce titre, devoir faire
de temps à autres des sauvegardes complètes est rédhibitoire.
- Accéder aisément à la dernière sauvegarde qui, par expérience, est
celle que j'utilise le plus souvent.
> L'argument sur la taille est bien sûr tout à fait justifié (et
> l'exemple d'une parfaite pertinence) mais pour ma part j'ai préféré
> joué la sécurité et donc choisi rsnapshot pour sauvegarder les VM LXC
> du boulot.
J'utilise beaucoup de VM mais la volumétrie des images disque fait que
j'ai abandonné tout espoir de les sauvegarder de manière régulière,
d'autant plus qu'avec une VM, la sauvegarde différentielle perd
drastiquement en efficacité : pour l'outil de sauvegarde, l'image disque
n'est qu'un blob binaire et il ne peut savoir de l'extérieur si un
secteur est occupé ou non. Du coup, il suffit que ce secteur ait changé
pour qu'il le sauvegarde, même si ce secteur ne contient rien au moement
de la sauvegarde. Exemple extrême mais réel avec une VM utilisée pour du
test unitaire et de la génération de paquet :
1. Je récupère les sources de l'application et les données de test
(500 Mo de sources pour l'appli + 3,6 Go de données).
1. Je compile dans la VM notre application, ce qui produit 14 Go de
fichiers intermédiaires ou finaux en mode debug.
2. Je déroule la batterie de 2900 tests unitaires qui produisent à leur
tour moult fichiers de données et de logs.
3. Comme tout passe, je lance la génération des paquets (re-compilation
en mode release) et je pousse des paquets sur notre référentiel de
paquets.
4. Je supprime toute l'arborescence.
Si je mets de côté ce qui s'est passé entre temps au niveau système (par
exemple, les écritures dans /var/log), je peux dire que j'en suis revenu
au point de la veille. L'état intrinsèque de la VM n'a pas bougé. Pour
autant, l'outil de sauvegarde va détecter l'équivalent de plusieurs
dizaines de Go de changement dans le fichier image de la VM et va donc
me produire un « diff » gigantesque.
Pour cette raison, je fais tourner rdiff-backup dans les VM et sur le
serveur hébergeant les VM mais pour de dernier, je lui demande d'ignorer
les images de disques des VM.
> On peut cependant pondérer (voire ignorer) ce risque en dédoublant les
> sauvegardes comme tu l'indiques !
J'ai fait court mais en réalité, j'ai trois supports de sauvegarde. Mes
données (photos, textes, code) valent bien plus à mes yeux que les
3 x 100 euros que peuvent coûter des disques.
> Juste une question : est-ce que le calcul du diff (de rdiff-backup)
> est moins consommateur de temps pour une sauvegarde sur disque externe
> (pas de réseau) qu'une duplication "à la rsnapshot" ?
À moins que les volumes à transférer ne soient importants en regard de
la bande passante disponible, rdiff-backup est bien moins efficace
lorsqu'on effectue une sauvegarde sur un disque externe local que sur
une machine « distante ». En effet, pour calculer le différentiel, il
doit lire l'intégralité du fichier précédemment sauvegardé. Si tu
utilises un disque externe, c'est l'instance locale de rdiff-backup qui
se charge de cette lecture (et qui commence donc par lire le disque
externe). Si tu utilises une machine tierce, rdiff-backup lance une
instance sur cette seconde machine qui travaille en parallèle de la
première et calcule les sommes de contrôle sur le serveur de sauvegarde
pendant que ton instance locale travaille sur les fichiers de ta
machine.
D'ailleurs, je conseille vivement des disques externes disposant d'une
interface USB3, ça vous change la vie. :)
> Et puisqu'on y est, une deuxième question : comment se comporte
> rdiff-backup sur les fichiers spare (genre machines virtuelles par
> exemple) ?
Je ne sais pas ce que tu entends par « fichier spare » dans ce cas.
Sébastien
--
Sébastien Dinot, sebastien.dinot@free.fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !
Reply to: