Forum Linux.général Rsync : sauvegarde incrémentale de gros fichiers

Posté par . Licence CC by-sa
4
20
nov.
2014

Bonjour,

Je sollicite la communauté car j'ai un soucis avec RSYNC.
J'ai une base de données MongoDB qui contient un bon To de données.

Cette base est sauvegardée via "mongodump" toutes les nuits localement sur la machine qui l'héberge (nous l'appellerons "srvMaster" pour faciliter la compréhension).
Je conserve deux dumps : celui du jour précédent et celui du jour J.
Le fichier produit par mongodump est purement binaire.

Le lendemain matin, un deuxième serveur "srvSlave" vient chercher la sauvegarde du jour J la rapatrie en local.

L'arborescence est la suivante :

  • sur srvMaster :

    • dernière sauvegarde : /home/backup/mongo/
    • sauvegarde J-1 : /home/backup/mongo_prev/
  • sur srvSlave :

    • dernière sauvegarde : /home/backup/mongo/
    • sauvegarde J-1 : /home/backup/mongo_prev/

Le problème est que RSYNC télécharge l'ensemble des gros fichiers binaires et non le delta. Ma base de données ne fait que de l'insertion (aucun delete, aucun update) donc j'imagine (selon les mécanismes de MongoDB) que les nouvelles données sont toujours en fin de dump.

Au début, je faisais transiter le RSYNC sur un montage NFS mais on me l'a déconseillé. Je me suis donc orienté sur RSYNC over SSH : même soucis.

Les commandes sont toujours exécutées depuis srvSlave donc je tire les données.
Voici quelques essais :

  • d'abord des essais en local : /usr/bin/sudo -u nobody /usr/bin/rsync -av --delete /home/backup/mongo/* /home/backup/mongo/. /usr/bin/sudo -u nobody /usr/bin/rsync -av --stats --delete --partial --inplace --no-whole-file --checksum /home/backup/mongo/* /home/backup/mongo/.
  • puis à distance : /usr/bin/sudo -u nobody /usr/bin/rsync -av --stats --delete --partial --inplace --no-whole-file --checksum -e "ssh -o StrictHostKeyChecking=no -i /key/id_rsa_for_backup" backup@srvMaster:/home/backup/mongo/* /home/backup/mongo/. /usr/bin/sudo -u nobody /usr/bin/rsync -av --delete -e "ssh -o StrictHostKeyChecking=no -i /key/id_rsa_for_backup" backup@srvMaster:/home/backup/mongo/* /home/backup/mongo/. J'ai essayé d'autres combinaisons (sans --checksum par exemple) mais j'ai toujours le soucis. Les deux machines sont sur Gentoo ; le shell par défaut est bash ; la version de RSYNC est 3.0.9-r3.

Est-ce que quelqu'un aurait une idée ? En sachant que ça ne vient pas du transfert via le réseau puisqu'en local j'ai également le soucis.

J'ai posé la question sur les forums Gentoo : on m'a juste dit de ne pas transférer via NFS mais le soucis reste le même en passant par SSH.

Je vous remercie d'avance

  • # gzip

    Posté par (page perso) . Évalué à 3.

    Hello,

    Je sais que gzip à un mode de "compatibilité" rsync
    gzip --rsyncable

    Si il n'existe pas d'option semblable pour organiser les données par bloc spécifiquement à ton export mongodb, à mon avis c'est mort…

    Nicolas

    • [^] # Re: gzip

      Posté par . Évalué à 2.

      Donc ça viendrait de rsync qui ne voit pas la modification dans son "block-size" habituel et qui prends la décision de tout synchroniser ?

      • [^] # Re: gzip

        Posté par . Évalué à 2.

        L'algo de base de rsync est simple.

        Si mod-time différent => transfert.
        Si mod-time identique et taille différent => reprise de transfert.

        Tu peux peux être jouer avec --checksum et --block-size=SIZE de rsync. avec un SIZE assez petit.

        • [^] # Re: gzip

          Posté par . Évalué à 1.

          J'ai essayé "--checksum" tout court sans "--block-size=SIZE".
          Tu mettrais quoi comme "--block-size" ? Je trouve pas d'information sur son fonctionnement :-/

          • [^] # Re: gzip

            Posté par (page perso) . Évalué à 5.

            à ma connaissance,RSYNC ne transfère que les blocs de fichier qui diffèrent entre le master et le slave

            le slave demande un bloc au master, chacun calcule une somme de contrôle de son côté, si les sommes sont différentes ---> transfert du bloc de fichier, et on passe au bloc suivant

            mais il ne faut pas s'amuser à compresser ou chiffrer ses fichiers avant le RSYNC, sinon il y a de bonne chances que tous les blocs soient différents (comme dis plus haut, une option de gzip permet de palier ce problème, merci pour l'info :-)

            tu dis que tu ne fais que des insert dans ta bdd et tu en déduis que ton dump au format binaire ne diffère que vers la fin, est-ce que tu as vérifié (peut-être que le dump est compressé par défaut) ???

            Envoyé depuis mon Archlinux

            • [^] # Re: gzip

              Posté par . Évalué à 1.

              J'ai toujours utilisé rsync dans ce but oui… Genre pour des migrations ou tu fais un premier rsync à chaud puis un delta à froid pour redémarrer rapidement.

              Mais bizarrement sur des gros fichiers il n'a pas le même comportement.

              Non je ne le déduis pas ; je pense que c'est comme ça. Par contre j'ai aucun élément de réponse… :-/
              La documentation sur mongodump est light mais j'ai comme l'impression que le dump n'est pas compressé par défaut :

              To send the database dump to standard output, specify “-” instead of a path. Write to standard output if you want process the output before saving it, such as to use gzip to compress the dump.

              Mais j'ai remarqué ce soucis avec d'autres gros fichiers binaires donc, sauf erreur de ma part, je pense pas que ce soit lié au dump Mongo spécialement :-/

            • [^] # Re: gzip

              Posté par . Évalué à 1.

              Je confirme : je viens de faire un test de rsync en prenant un répertoire MySQL bien lourd (base démarrée) et au deuxième rsync, sur les gros fichiers, il sync full :-/

              • [^] # Re: gzip

                Posté par (page perso) . Évalué à 2. Dernière modification le 20/11/14 à 19:00.

                des fichiers de bdd ça bouge beaucoup (un changement de structure, une optimisation, et le fichier est presque entièrement différent)

                tu as analysé les différences de fichiers entre 2 rsync (commande cmp par exemple) ?

                petite expérience :
                prend un de tes gros fichiers, fais un rsync,
                puis concatène avec un fichier plus petit,
                refait un rsync et observe

                si tout le fichier est retransféré il y a effectivement un pb, ou un bug, ou option de rsync pas adaptée (tu n'es pas le premier à constater ce comportement, mais je n'ai encore lu de diagnostic du pb, ni de solution…)

                Envoyé depuis mon Archlinux

                • [^] # Re: gzip

                  Posté par . Évalué à 1.

                  Je viens de faire le test suivant :
                  - copier un fichier de la DB qui tourne vers un répertoire "tmp"
                  - copier ce fichier de "tmp" vers "src"
                  - rsync -av --stats --progress src/* cible/. : sync full (normal)
                  - concaténation d'un petit fichier de DB dans src/fichier_origine
                  - rsync -av --stats --progress src/* cible/. : à nouveau un sync full :'(

                  Je ne comprends vraiment pas le problème :-/

                  • [^] # Re: gzip

                    Posté par (page perso) . Évalué à 1.

                    tu as bien un daemon rsync (serveur) qui tourne sur la machine cible capable de répondre à ta commande rsync locale (client) ?

                    parce que j'ai l'impression que tu ne fais que de la copie entre un répertoire local et un répertoire distant au moyen d'un accès ssh, et dans ce cas, tu auras les mêmes échanges qu'avec un rsync purement local

                    Envoyé depuis mon Archlinux

                    • [^] # Re: gzip

                      Posté par . Évalué à 1.

                      Bonjour,

                      Effectivement je n'ai pas le daemon rsync (ni sur le serveur source, ni sur le serveur cible). Par contre, quand je fais un rsync purement local (comme celui de mon dernier commentaire), il faut également le daemon ?!

                      • [^] # Re: gzip

                        Posté par (page perso) . Évalué à 1. Dernière modification le 21/11/14 à 10:30.

                        en local, aucun intérêt, rsync n'utilisera pas son algo delta,

                        cet algo qui permet de transmettre uniquement les différences d'un fichier n'a d'intérêt que lors d'un transfert entre 2 processus RSYNC qui disposent chacun d'un cpu distinct et à travers un réseau dont la bande passante est (très) inférieure aux débits des disques

                        en local, il y a 1 seul rsync qui tourne, le fichier source va être lu intégralement, et le fichier destination va être aussi créé en totalité,
                        pas la peine de calculer les différences sur un fichier, c'est du travail superflu

                        désolé si pas très clair, au boulot, pas trop le temps de développer, mais tu trouveras pleins de tuto et d'explication sur le principe de fonctionnement de RSYNC, faut juste réaliser qu'il y a 2 utilisations (1 RSYNC isolé, ou 2 RSYNC qui causent entre eux)

                        Envoyé depuis mon Archlinux

                        • [^] # Re: gzip

                          Posté par (page perso) . Évalué à 1.

                          je ne crois pas (= je sais) que le démon rsync soit nécessaire si on passe par ssh comme le fait kortex.

                          Concernant le delta, c'est vrai qu'il ne sert a rien local mais en théorie, dans la mesure ou kortex utilise l'option no-whole-file, cela devrait forcer le calcul du delta (même si c'est contre productif, mais on s'en fout c'est pour le test).

                          dans tout les cas l'algo de delta n'est utilisé que pour les octet à tranférer, dans tout les cas les fichier sont source et destination sont lu, et au moindre bit de différence entre les 2 le fichier de destination est intégralement réécris (j'ai testé avec l'option inplace: le fichier est réécris par dessus l'ancien, mais réécris qd meme).

                          Le bilan: rsync permet d'optimiser la bande passante au prix des IO disque.

                          • [^] # Re: gzip

                            Posté par . Évalué à 1.

                            Du coup ce n'est pas un bug chez moi mais bien un comportement généralisé :/

                            Yohann comme tu semble avoir les mêmes résultats que moi, est-ce que tu as une solution pour ne copier que le delta ?
                            Précision tout de même : je n'utilise pas toujours --inplace et/ou --no-whole-file. J'ai fais plusieurs essais donc le classique rsync -av src/* cible/. et même combat :(

                            Pour résumer, je viens de refaire quelques essais :

                            • je rsync un gros fichier (27 Go)
                              rsync -av --stats --progress src/* cible/.

                            • je relance le rsync : plus rien à faire (normal)

                            • je concatène un fichier binaire assez léger (12 Ko) à la fin du gros fichier source :
                              cat binary_12k >> src/gros_fichier

                            • je relance le rsync avec différentes combinaisons :

                              • "-av --stats --progress" : même soucis
                              • "-av --stats --progress --no-whole-file --checksum" : même soucis
                              • "-av --stats --progress --no-whole-file --checksum --inplace" : même soucis
                              • "-av --stats --progress --no-whole-file --checksum --inplace --block-size=512" : même soucis
                              • "-av --stats --progress --no-whole-file --checksum --inplace --block-size=4096" : même soucis
                            • [^] # Re: gzip

                              Posté par . Évalué à 2.

                              Je comfirme les résultats avec l'option --checksum.

                              Par contre, j'ai trouvé un cas où on peut simulée une reprise de transfert.

                              rsync -avP systemrescuecd-x86-4.3.0.iso moi@localhost:/tmp/site/
                              cat 10mo >> systemrescuecd-x86-4.3.0.iso
                              cat 10mo >> systemrescuecd-x86-4.3.0.iso
                              touch systemrescuecd-x86-4.3.0.iso /tmp/site/systemrescuecd-x86-4.3.0.iso
                              rsync -avP systemrescuecd-x86-4.3.0.iso moi@localhost:/tmp/site/

                              J'obtiens alors une reprise de transfert par rsync comme si le fichier original n'avait pas bougé. Je déduis cela de la vitesse de transfert affiché par rsync qui est inhabituellement élévée en début pour finir avec les valeurs habitelles.

                            • [^] # Re: gzip

                              Posté par (page perso) . Évalué à 2.

                              malheureusement non, comme expliqué, la vocation de rsync est de réduire l'utilisation de la bande passante, pas tellement l'utilisation du disque (ni en terme d'espace, ni en terme d'IO).

                              par contre les terme sont assez imprécis : si on considérer le fichier A à t0 composé de 1111 et à t1 composé de 1110 et qu'on le transfère en utlisant rsync, voilà ce qui va arrivé dans le cas optimum:

                              A sur src et A sur dest font ils la meme taille et ont-il la meme date de modification (si non on déclenche le transfert)

                              On lit A sur src et on calcule son checksum
                              On lit A sur desc et on calcule son checksum

                              sont-il identique ? (si non on commence le transfert)

                              On lit le premier chunk de A: 1 on réalise son checksum
                              on lit le premier chunk de B: 1 on rélise son checksum
                              si les checksum son identiques on copie le début du fichier depuis le Fichier A sur dest dans un fichier temporaire (sauf si inplace auquel cas on écrit au début de A sur Dest (oui on remplace 1 par un nouveau 1)

                              sinon on copie depuis A sur src.

                              On recommence avec des block de plus en plus gros tant que ça fonctionne.

                              • [^] # Re: gzip

                                Posté par . Évalué à 1.

                                Bonjour,

                                Je te remercie pour l'explication mais malheureusement il y a toujours une chose que je ne comprends pas. Tu dis que RSYNC optimise la bande passante et non les I/O. Mais quand je concatène 12 Ko au bout d'un fichier de 27 Go et qu'il se met à transférer les 27 Go, c'est pas super économe :-/

                                Du coup par rapport à ton explication j'en déduis que je ne dois pas utiliser "--inplace" mais malgré tout je ne trouve pas LA combinaison qui fait qu'il va syncer un delta.
                                Ça n'existe pas ?

                                • [^] # Re: gzip

                                  Posté par (page perso) . Évalué à 1.

                                  en fait a moins d'être en local il ne transfère pas les 27 GO.
                                  mais de mémoire "l'interface graphique" (le truc qui apparait quand on lance avec --progress) rend ça transparent. (mais affiche des débit largement supérieur à ta BP du coup du comprend qu'il se passe quelque chose de magique).
                                  Et, une fois le transfert terminé, il affiche le nombre d'octet qui a effectivement transité sur le réseau.

                                  • [^] # Re: gzip

                                    Posté par . Évalué à 1.

                                    Les tests étaient tellement longs à effectuer que j'ai utilisé l'option "-n" pour simuler ce qu'il se passerait et je me suis fié aux valeurs affichées dans le rapport final ; si ce mode simulation est une image de la réalité, il transfert 100% :-/

                                    Tous les tests que j'ai fais réellement (sans le "-n") ont confirmé ce transfert complet (en local comme à distance).
                                    J'ai quand même du mal d'imaginer que je suis le seul qui ait besoin de transférer un delta de fichiers volumineux :-/

                                    • [^] # Re: gzip

                                      Posté par . Évalué à 2.

                                      il te manquerait pas un --partial pour garder ce qui est deja sur la destination ?

                                      perso je fais mes transferts avec
                                      rsync -aP SRC DST

                                      • [^] # Re: gzip

                                        Posté par . Évalué à 2.

                                        C'est vrai que c'est con. -P est l'alias de "--partial --progress". Je le fous tout le temps pour avoir le --progress. Si bien que j'en oublie qu'il fait aussi --partial.

                                        • [^] # Re: gzip

                                          Posté par . Évalué à 1.

                                          D'après le man, "--partial" ne sert qu'à la reprise en cas de coupure du transfert. J'ai essayé --partial avec l'option -n et pareil :
                                          Total file size: 28735205960 bytes
                                          Total transferred file size: 28735205960 bytes

                                          • [^] # Re: gzip

                                            Posté par . Évalué à 2.

                                            Je ne ferais pas confiance à ce qu'annonce rsync comme débit, taille transfert.

                                            Je pense que le mieux est de faire un dump de ce qui passe et de calcul son poids.

                                            • [^] # Re: gzip

                                              Posté par . Évalué à 1. Dernière modification le 28/11/14 à 10:36.

                                              Oui mais je n'ai pas commencé par lui faire confiance aveuglément :-)
                                              Quand je lance réellement le transfert je peux t'assurer qu'il transfert tout (taille en MB/s * temps = la taille du fichier).

                                              Hors, je ne rajoute que 12 Ko à la fin d'un fichier binaire de 27 Go :
                                              bash
                                              cat fichier_binaire_12K >> fichier_binaire_27G

                                              L'option "-n" n'est peut être pas la plus fiable mais dans mon cas je pense qu'elle fonctionne correctement :-/

  • # rdiff-backup et rdiff-backup-fs

    Posté par (page perso) . Évalué à 1.

    • [^] # Re: rdiff-backup et rdiff-backup-fs

      Posté par . Évalué à 1.

      Ce soft m'a l'air intéressant effectivement mais dans la mesure ou je ne sauvegarde pas un répertoire mais un dump, est-ce qu'il va réussir à faire le delta ?
      Désolé pour la solution de facilité (poser la question au lieu de tester) mais je suis un peu court niveau temps ces jours-ci :-/

  • # Toujours pas de solution

    Posté par . Évalué à 1.

    Bonjour,

    J'ai mené différents essais ces derniers jours et j'en suis toujours au même point.
    Côté RSYNC :
    - tests sur Gentoo et Debian wheezy
    - avec différentes combinaisons d'options
    - avec un daemon RSYNC côté source ET côté cible
    - sans daemon RSYNC
    - sur montage NFS
    - à travers SSH

    J'ai toujours le même comportement…

    Côté RDIFF-BACKUP : mes premiers essais ne me conviennent pas. Ca n'a pas la souplesse / la simplicité de RSYNC :-/

    Avant je travaillais sur Solaris et je migrais des zones locales en deux temps :
    - j'amenais un nouveau volume de disques
    - je faisais une première synchronisation (groupe de disques actuel => nouveau groupe de disques) pendant que la zone était en exécution
    - je coupais la zone
    - je faisais une deuxième synchronisation à froid : je n'avais que le delta

    Hors, je n'utilisais qu'une commande simple : rsync -av --delete source cible

    Pourquoi le rsync de Linux n'a pas ce comportement ?
    Si quelqu'un a des idées je suis preneur.

Suivre le flux des commentaires

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