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.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
