Re: Avec le sujet c'est mieux : Rsync et le système de fichiers qui va bien
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.dinot@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-REQUEST@lists.debian.org
> En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
> Archive: [🔎] 20140917122128.GC4791@hector.home.dinot.net">https://lists.debian.org/[🔎] 20140917122128.GC4791@hector.home.dinot.net
>
>
--
Bertrand Orvoine
Reply to: