Journal Synchroniser deux répertoires rdiff-backup

Posté par  (site web personnel) .
Étiquettes :
4
23
jan.
2012

Bonjour à tous,

J'étudie un nouveau système de sauvegarde basé sur rdiff-backup. Actuellement j'utilise rsync avec des liens symboliques pour gérer la "déduplication" ça marche mais ça reste gourmand en espace et en volume de données tranférées.

Un bout de l'archi : tout les soirs les serveurs copient leurs données sur un disque monté en nfs et de différentes méthodes, la majorité c'est rsync. Je l'appelle dépôt 1, ensuite dépôt 1 est synchronisé sur le même principe (rsync + cp -l) sur un disque usb qui s'appelle dépôt 2.

L'idée est de remplacer tout les rsync par rdiff-backup, donc les serveurs envoie via rdiff dans dépôt 1, ensuite en journée dépôt 2 est mis à jour par rdiff avec les données de dépôt 1. Ma grande question est comment vont ce comporter les dossiers et fichiers propre au fonctionnement de rdiff du dépôt 1 ? Vont-ils être copiés comme de bête fichiers/dossiers et écraser ceux de dépôt 2 ? Ou alors rdiff est capable de gérer ça.

La finalité est que si le gain de volume transféré est important je me passe de backup usb pour m'orienter vers un serveur distant prévue pour.

Avez-vous monté ce genre d'architecture ?

  • # oui, avec dirvish

    Posté par  (site web personnel) . Évalué à 3.

    Je l'ai fait avec Dirvish, comme pas mal de monde l'utilisant. C'est même prévu pour! Même si tu ne t'en sers pas, tu devrais trouver des exemples et des conseils utiles dans le wiki et les archives de la liste Dirvish.
    http://www.dirvish.org/

    "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

  • # rsync

    Posté par  (site web personnel) . Évalué à 3.

    Juste deux détails pour faire mon chieur.

    rsync avec des liens symboliques pour gérer la "déduplication"

    Tu veux dire des liens hard

    rsync + cp -l

    rsync sait faire ça comme un grand

    man rsync 
/--link-dest=

    • [^] # Re: rsync

      Posté par  (site web personnel) . Évalué à 1.

      Oui pardon c'est bien des hards links que j'utilise.

      man rsync
      /--link-dest=

      Je l'ai pas vu celle-la faut que je creuse.

      Born to Kill EndUser !

  • # --linkdest

    Posté par  . Évalué à 3.

    Pourquoi rdiff-backup consommerait moins qu'un "rsync --linkdest" ?

    • [^] # Re: --linkdest

      Posté par  (site web personnel) . Évalué à 1.

      De ce que j'ai lu rsync transfert les fichiers modifiés et rdiff les bouts de fichiers modifiés... Enfin d'après ce que j'ai compris.

      Born to Kill EndUser !

      • [^] # Re: --linkdest

        Posté par  (site web personnel) . Évalué à 2.

        Il me semble de rdiff-backup utilise librsync donc ca revient au même.
        De plus rsync est fait pour n'envoyer que ce qui a changé donc normalement tu ne devrais pas avoir beaucoup de transferts.

      • [^] # Re: --linkdest

        Posté par  . Évalué à 7.

        rsync transfert les fichiers modifiés et rdiff les bouts de fichiers modifiés

        rsync transfère les parties de fichiers modifiées, tout comme rdiff-backup. Ce qu'apporte rdiff-backup, ce sont les sauvegardes incrémentales, qui vous permettent de restaurer d'anciennes versions de fichiers par exemple.

    • [^] # Re: --linkdest

      Posté par  (site web personnel) . Évalué à 2.

      En terme de trafic réseau, ce sera pareil dans la mesure où rdiff-backup utilise le protocole rsync.

      En revanche, c'est au niveau du stockage que rdiff-backup est intéressant, car il ne stocke que les différences apportées au fichier depuis la dernière version.

      Avec rsync --linkdest, si le fichier a été modifié, le lien est "brisé" et c'est une nouvelle version complète qui est recopié.

      Conclusion: rdiff-backup permet d'économiser de l'espace disque et est intéressant pour sauvegarder des fichiers volumineux modifiés fréquemment (pst, dump de bases de données, ...).

      Par contre, il est nécessaire de passer par rdiff-backup pour la restauration des fichiers.

      My random 2¢

      • [^] # Re: --linkdest

        Posté par  (site web personnel) . Évalué à 1.

        Des fichiers volumineux genre pst, dump... c'est exactement le genre de fichiers qui me posent problèmes. Les fichiers utilisateurs bougent peu donc facile à gérer mais pour les dump oracle, mysql et ces satanés fichiers pst c'est la galère.

        Donc l'intérêt de rdiff est dans le gain de d'espace de disque et non le gain de consommation de bande passante.

        Born to Kill EndUser !

      • [^] # Re: --linkdest

        Posté par  . Évalué à 4.

        Par contre, il est nécessaire de passer par rdiff-backup pour la restauration des fichiers.

        Uniquement si on ne veut pas restaurer la version la plus récente.

        La sauvegarde la plus récente est une arborescence de fichiers identique à l'original. rdiff-backup n'est indispensable que pour restaurer des fichiers plus anciens car rdiff-backup les reconstitue à partir des différences avec la dernière version..

  • # tcp sur tcp

    Posté par  (site web personnel) . Évalué à 3.

    Si je comprends bien, tu veux faire un rdiff-backup au dessus d'un rdiff-backup ! sachant que l'algo sous jacent est le même que rsync (librsync), pourquoi ne pas faire bêtement un rsync entre dépôt 1 et dépôt 2 à la fin ? Sur le dépôt 2, tu auras tout l'historique qu'il y a sur le dépôt 1...

    • [^] # Re: tcp sur tcp

      Posté par  (site web personnel) . Évalué à 1.

      Je partais du principe (faux) que rdiff transférait que les bouts de fichiers modifiés alors que rsync transférait la totalité d'un fichier modifié.

      Born to Kill EndUser !

  • # Même pas peur…

    Posté par  . Évalué à 6.

    J’en profite pour y aller moi aussi de ma petite question, et ça pourrait donner des idées à ceux qui n’ont pas froid au yeux…

    Y’en a qui ont tenté d’utilise btrfs (ou tout autre système de fichier adéquat) comme système de sauvegarde ?

    Entre la compression à la volée et les snapshots avec le copy on write j’ai pu monter un système de sauvegarde simplissime. Il m’a semblé que ça consommait un peu plus de mémoire que rdiff-backup, par contre c’est beaucoup plus rapide et la méthode pour accéder aux fichiers est plus standard (pas besoin de faire appel à un programme, il suffit de parcourir l’arborescence).

    Voici la ligne de commande :

    mount /mnt/backup;rsync -av --inplace --delete --filter="merge $HOME/.rsync.pattern" ~ /mnt/backup/latest;[ -d /mnt/backup/`date +'%Y-%m-%d'` ]||sudo btrfs subvolume snapshot /mnt/backup/latest /mnt/backup/`date +'%Y-%m-%d'`;df -h;umount /mnt/backup

    /mnt/backup est le point de montage d’un volume btrfs appelé backup et latest est un sous volume. Tous les jours je créé un snapshot. La compression est une option de montage (zlib pour les sauvegardes). Et j’utilise le classique rsync pour faire la synchro.

    Après quelques jours ça se présente sous cette forme :

    ~ ls /mnt/backup 
2012-01-14/  2012-01-15/  2012-01-16/  2012-01-17/  2012-01-18/  2012-01-19/  2012-01-20/  2012-01-21/  2012-01-22/  2012-01-23/  latest/

    J’améliorerai le système pour effacer les snapshots de plus de 1 mois, sauf ceux du premier de chaque mois, idem sur 1 ans, etc.

    • [^] # Re: Même pas peur…

      Posté par  (site web personnel) . Évalué à 3.

      Ca tient la charge ? J'avais tenté la même chose avec LVM il y a quelques années mais c'était ingérable du fait de LVM...

      Un point important serait lors des backup de ne sauver que les block qui ont été modifié depuis le dernier backup... Comment avoir cette liste des block modifié sur le serveur de base, via un snapshot LVM :

      http://serverfault.com/questions/27397/sync-lvm-snapshots-to-backup-server
      http://theshed.hezmatt.org/lvmsync/

      lvmsync semble intéressant ! J'ai pas encore testé. Il y a juste un truc qui me chiffonne, il faut faire un snapshot LVM sur la source juste pour avoir la liste des block modifié... LVM fait bien plus que cela donc ralentis... Il serait intéressant d'avoir un snapshot LVM qui liste juste les block modifié sans dupliqué ces block. On n'aurait alors aucune perte et performance quasiment. Je ne sais pas si cela existe...

      Sinon, plutôt que LVM, peut être qu'il est possible d'avoir la liste des fichiers modifiés via lsyncd et de n'envoyer à rysnc ou rdiff-backup que cette liste histoire de gagner encore du temps ! Je ne sais pas comment se comporte lsyncd sur une grosse arborescence de millions de fichiers sur 30To par exemple...

      • [^] # Re: Même pas peur…

        Posté par  . Évalué à 2.

        Pour utiliser ce système, j'atteste du fait que ça tient extrêmement bien "la charge". Chaque snapshot est vu comme un répertoire (au statut un peu particulier) et on peut en conserver autant que l'espace disque (réellement utilisé) le permet. Le rsync ne transfère que les blocs modifiés et le --inplace fait que rsync écrit directement dans le fichier de destination plutôt que d'écrire dans un fichier temporaire qui remplacera le fichier de destination après coup (créant au passage une nouvelle copie de chaque fichier dans des "blocs tous neufs" qu'on ne partagerait alors plus avec les snapshots précédents).

        btrfs power ! ZFS et sa suite logicielle ont encore de l'avance mais btrfs la grignote chaque jour. Pour de la sauvegarde, la déduplication (que btrfs ne fait pas encore) est aussi un plus. Quelqu'un aurait testé le même principe de sauvegarde avec ZFS ou lessfs (lui aussi prometteur, libre et centré sur la déduplication) ?

        • [^] # Re: Même pas peur…

          Posté par  (site web personnel) . Évalué à 2. 

          Quelqu'un aurait testé le même principe de sauvegarde avec ZFS ?

          C'est ce que j'utilise au boulot, sur 2 OS : Slowlaris et Debian (avec ZOL).

          Les principes sont les mêmes : snapshots human-readable, dedup, compression, backup incrémentaux, rotation, etc.

          Si vous voulez jouer avec zfs, sur un linux, il y a ZOL (http://zfsonlinux.org/ ). ZOL, c'est bon, mangez-en. Debian aussi, c'est bon, mangez-en. (Non, on est pas 'dredi !)

          C'est en prod, sur des R510 (Dell/Debian) et des X4500 (Sun/Debian). Ça juste tourne.

          Proverbe Alien : Sauvez la terre ? Mangez des humains !

          • [^] # Re: Même pas peur…

            Posté par  (site web personnel) . Évalué à 3.

            Avez vous essayer sur des partitions de 15To par exemple ayant des millions de fichiers ? Cela tiens ? Ce qui m'ennuie avec btrfs, c'est qu'il n'y a pas encore de fsck je crois...

            Sinon, n'étant pas sur que lsyncd tiennent la charge sur des millions de fichiers, ce serait effectivement bien de pouvoir faire un snapshot sur l'original qui garde un journal des fichiers modifié/ajouté/supprimé afin de lancer le backup sur ces seuls fichiers et avoir encore un gain très important sur le temps passé à la sauvegarde. Je ne sais pas si btrfs fait cela (ou ZFS).

            Évidement, il faut alors contrôler ensuite une partie aléatoire des données pour être sur qu'elle sont toujours bonne, de l'ordre de 1%. C'est comme cela que fait backuppc lorsqu'on utilise l'option --checksum-seed de rsync (voir option RsyncCsumCacheVerifyProb).

            • [^] # Re: Même pas peur…

              Posté par  . Évalué à 1.

              Oui, btrfs oublie, je ne me permet de l’utiliser que parce que c’est un usage personnel, pour seulement ~25 Go de données. Non seulement il n’y a pas de fsck (quoique il y a bien un utilitaire btrfsck, mais pas l’attendu fsck.btrfs — aucune idée de la différence entre les deux). Et contrairement à ce qui est indiqué un peu partout, j’ai eu la surprise de voir que le format n’est pas encore réellement stable : « As of 2.6.31, we only plan to make forward compatible disk format changes », et il faut un noyau récent qui plus est.

              Pour ce qui est des performances, je ne me risquerai pas à extrapoler sur des To, et d’autres ont mieux répondu que moi pour de gros volumes. Mais il ne faut pas oublier que pour la copie c’est toujours rsync --inplace qui travaille donc le gain en bande passante et écriture disque est toujours là. Là où j’avais peur c’était que la création des snapshots soit longue, mais en fait c’est quasi-instantanné (et je doute que ça dépende du volume). Je ne connais pas la surcharge liée au copy-on-write ou à la compression (là encore, pour un usage domestique avec une sauvegarde à travers l’usb qui se traîne à 30 Mo/s, je ne peut pas extrapoler avec une utilisation industrielle). Dans tous les cas je m’en tire avec de meilleures performances que rdiff-backup, sans avoir fait de mesures précises.

            • [^] # Re: Même pas peur…

              Posté par  (site web personnel) . Évalué à 2.

              Je ne vais répondre que sur mon expérience avec zfs.

              Mes volumes zfs (equiv partition) vont de 2To à 20To net.
              J'y fais tourner :
              - un db4 pour un code de calcul "àlacon" en test (dans le 2To),
              - un mysql (zabbix pour 200 nodes) + postgresql (OSM) (dans un volume de 8To),
              - des /home de cluster de calcul (5x 20To) <= des millions de fichiers,
              - un volume de backup (compression, dedup) pour tous les autres volumes qui y envoient leurs snapshots (20To).

              Les snapshots sont trés rapide, leur transfert un peu moins :o). Ça reste plus rapide qu'un rsync entre serveur. zfs est un fs orienté écriture, donc pas ultra performant à la lecture (et j'ai eu des surprises).
              On ne s'embête même plus avec un logiciel de sauvegarde, tout dans les snapshots (en snapdir=visible).

              Pour ce qui est de l'intégrité des données, c'est assez rock-solid. Un de nos serveurs a eu une barrette de ram defectueuse, et après moult vérifications : Pas un seul octet corrompu sur les disques.

              Proverbe Alien : Sauvez la terre ? Mangez des humains !

    • [^] # Re: Même pas peur…

      Posté par  (site web personnel) . Évalué à 1.

      J’utilise un script perso qui fait du rsync puis crée un snapshot. Les (ana)cron adéquats me permettent d’avoir les 5 derniers jours, les 4 dernières semaines, les 3 derniers mois.

      Le tout est (était) sauvegardé sur du ZFS-fuse dédupliqué compressé, sans problème quelconque. J’ai commencé avec Mandriva, continué avec Arch : la transition s’est fait en douceur.

      Quant à mon « était » ci-dessus, c’est parce qu’hier, j’ai utilisé gparted sans faire attention pour agrandir la partition de backup. Je n’avais pas vu que gparted croyait que cette partition était du Ext4, et quand j’ai vu le resize Ext se déclencher, c’était trop tard :-/

      Bref, expérience plutôt positive pour rsync+ZFS. Maintenant que je dois repartir de zéro, je réfléchis à éventuellement essayer LessFS à la place ou peut-être ZfsOnLinux (module natif).

      Yves.

  • # duplicity

    Posté par  (site web personnel) . Évalué à 1.

    Si tu es soucieux sur tes transferts, tu peux regarder du côté de duplicity.

    Le fonctionnement est identique à rdiff-backup mais intègre un chiffrement à l'aide GPG sur les données transférées.

    https://link-society.com - https://kubirds.com

    • [^] # Re: duplicity

      Posté par  (site web personnel) . Évalué à 1.

      Je n'ai pas besoin de signer les sauvegardes et le transfert vers l'extérieur sera passer sur du ssh.

      Born to Kill EndUser !

    • [^] # Re: duplicity

      Posté par  . Évalué à 2.

      Pour sécuriser le transfert, rdiff-backup à travers SSH convient très bien.
      duplicity apporte en plus la sécurisation (chiffrement GPG) du stockage.

      J'utilise rdiff-backup pour des sauvegardes locales et duplicity pour des sauvegardes externalisées sur Amazon S3. rdiff-backup est quand même plus simple à utiliser.

  • # montage

    Posté par  . Évalué à 2.

    Attention au montage de système de fichier exotique avec rdiff-backup (basé sur python). De mémoire, je sauvegardais sur un disque distant via fusesmb (wai, je sais...) et il n'aimait pas trop.

  • # Plus simple.

    Posté par  . Évalué à -1.

    J'utilise ceci :

    http://www.ibiblio.org/pub/linux/docs/LDP/linuxfocus//Francais/March2004/article326.shtml

    comme ça tu choisis dans ton 2eme backup ce que tu veux mettre sur ton disque USB.

    a+

  • # backuppc ?

    Posté par  (Mastodon) . Évalué à 1.

    Après avoir utilisé longtemps rdiff-backup, je suis passé à rsnapshot pendant 2 ans, rdiff marche bien, mais il est souvent pénible de lister les différences et/ou de restaurer d’anciennes versions. Rsnapshot est pas mal, mais il est assez lent quand la volumétrie commence à vraiment monter.
    Depuis un peu plus d’un an, je suis passé à backuppc, le système utilisé permet une très bonne déduplication bien meilleure que les 2 précédents dès qu’on à plusieurs machines avec des fichiers communs ou qu’on fait de la réorganisation (renommage en masse de photos ou mp3, déplacement d’un dossier à un autre, synchronisation d’arborescence entre 2 machines…). Et il gère l’export en tar sur support externe (fonction archivage).

    • [^] # Re: backuppc ?

      Posté par  (site web personnel) . Évalué à 1.

      mais il est assez lent quand la volumétrie commence à vraiment monter.

      Je sais pas ce que tu pense par "vraiment monter", je gère en gros 250Go de données total et c'est ~100go qui transite tout les soirs donc pour moi ça fait beaucoup.

      BackupPc je l'ai testé surtout pour la sauvegarde côté utilisateur mais je me rappel plus pourquoi je l'ai pas conservé comme solution, faudrait que je refasse un test.

      Born to Kill EndUser !

      • [^] # Re: backuppc ?

        Posté par  (site web personnel) . Évalué à 2.

        J'ai essayé backuppc sur une partition de 10To ayant des millions de fichier, c'est inutilisable. Backuppc marche bien pour les homes des utilisateurs.

        rdiff-backup résoud le même problème en 15min...

      • [^] # Re: backuppc ?

        Posté par  (Mastodon) . Évalué à 1.

        Avec un Rsnapshot qui centralisait 25 serveurs pour 4To de backups, que des nouveaux fichiers, jamais de suppressions, presque pas de modifs, ça devenait limite utilisable, et tenait à peine dans la fenêtre 21h → 7h…

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.