On Wed, Sep 17, 2014 at 02:21:28PM +0200, Sébastien Dinot wrote: > 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.
je suppose qu'il voulait dire "sparse" file ? > > Sébastien > > > -- > Sébastien Dinot, sebastien.di...@free.fr > http://sebastien.dinot.free.fr/ > Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer ! > > -- > Lisez la FAQ de la liste avant de poser une question : > http://wiki.debian.org/fr/FrenchLists > > Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" > vers debian-user-french-requ...@lists.debian.org > En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org > Archive: https://lists.debian.org/20140917122128.gc4...@hector.home.dinot.net > > -- Bertrand Orvoine -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: https://lists.debian.org/20140917123301.gg13...@bop.univ-ubs.fr
