Forum général.général Rsync avec calcul des checksums simultanément

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
0
6
juin
2019

Bonjour tout le monde

Je synchonise des gros fichier (de l'ordre de 500Go) via Rsync et plus particulièrement la commande suivante :
rsync --times --inplace --no-whole-file /Datastore/VM1.img root@192.168.0.1:/Save/VM1.img

Ca fonctionne bien, puisqu'il synchronise l'image sans fichier temporaire et en n'envoyant via le réseau que la différence.
Cependant, quand je regarde l’occupation des machines, je constate le fonctionnement suivant :

sending incremental file list
Etape 1 : Lecture sur le serveur de destination

Copie du fichier
Etape 2 : Lecture sur le serveur source

Comment faire pour que l'étape 1 et 2 se déroule en même temps. Car c'est du temps perdu de voir les serveurs travailler chacun leurs tours.

  • # Tout se fait en même temps

    Posté par  . Évalué à 2.

    sending incremental file list
    Etape 1 : Lecture sur le serveur de destination

    Copie du fichier
    Etape 2 : Lecture sur le serveur source

    Cette explication n'est pas claire. Par exemple tu n'indiques pas à quel moment les données sont transférées. Tu indiques « Copie du fichier » mais ce n'est pas une étape numérotée, et après cette copie il y aurait une étape de lecture ce qui n'a aucun sens. De plus rsync ne fait une copie qu'en local, à distance c'est un transfert des différences qui se fait en même temps que la vérification des sommes de contrôles progressives (rolling checksum).

     

    Imagine que VM1.img fasse 200 Gio et que tes machines source et cible aient 16 Gio de mémoire.
    Il n'est pas réaliste que rsync fasse sa somme de contrôle progressive sur une machine et la garde en mémoire pour ensuite la comparer avec la même chose de l'autre côté --> la comparaison des fichiers se fait bien simultanément des deux côtés.
    Donc ce que tu vois est peut-être autre chose que ce que tu imagines.

    • [^] # Re: Tout se fait en même temps

      Posté par  . Évalué à 2.

      Merci c'est cool d'avoir du monde pour discuter.

      Je vais redéfinir plus précisément alors.

      Etape 1, juste après l’exécution de la commande, Rsync indique "sending incremental file list"
      Cette étape dure et je constate via atop une occupation disque en mode lecture sur le serveur de destination et rien su le serveur source.

      Puis arrive l'étape 2 où Rsync affiche la progession des pourcentage pour donner "exemple : 48,474,357,760 100% 26.23MB/s 0:29:22 (xfr#1, to-chk=0/1)"
      Durant cette étape, toujours via mes atop, je constate de la lecture sur la source cette fois ci et rien sur la destination.

      Au passage, il n'y a pas d'écriture car l'image est tellement modifiée.

      Tu as raison, je vais faire le test avec une image plus grande que ma RAM dispo. Mais en attendant, j'ai tout de même des accès en lecture sur la destination puis longtemp après sur la source. Je comprend pas pourquoi, où plus exactement j'aimerais que Rsync lance les check sur les 2 serveurs simultanément et synchronise que les blocs nécessaires.

    • [^] # Re: Tout se fait en même temps

      Posté par  . Évalué à 1.

      Kerro quand tu dit : "magine que VM1.img fasse 200 Gio et que tes machines source et cible aient 16 Gio de mémoire. Il n'est pas réaliste que rsync fasse sa somme de contrôle progressive sur une machine et la garde en mémoire pour ensuite la comparer avec la même chose de l'autre côté --> la comparaison des fichiers se fait bien simultanément des deux côtés."

      En fait une img qui fait 200Go, ce ne sont que les checksum qui sont gardé et ça rentrerait donc largement bien dans une RAM de 16Go. Donc pas de soucis, Rsync arrive bien à calculer et retenir l'ensemble des checksum des blocs du fichier destination avant de traiter la source.

      • [^] # Re: Tout se fait en même temps

        Posté par  . Évalué à 2.

        […] 200 Gio […] ce ne sont que les checksum qui sont gardé et ça rentrerait donc largement bien dans une RAM de 16Go.

        rsync fait des sommes de contrôles pour chaque bloc de 700 octets (de mémoire) : une somme de contrôle MD5 (128 bits) et une somme de contrôle « roulantes » (32 bits).

        200 Gio / 700 octets x 160 bits --> environ 6 Gio
        Tu verras facilement que rsync utilise beaucoup moins de mémoire que cela.

        Rsync stocke les sommes de contrôles aux alentours du bloc actuellement évalué, mais pas plus.

        • [^] # Re: Tout se fait en même temps

          Posté par  . Évalué à 3.

          Je viens de vérifier : sur les anciennes versions de rsync ça fonctionne comme j'ai expliqué. Mais sur les récentes (depuis plus de 6 ans) ça fonctionne avec la cible qui effectue d'abord les sommes de contrôles puis la source qui vérifie. Donc ça correspond à tes observations.

          Bon, je viens encore d'apprendre un truc important. C'est un changement majeur vu que rsync ne permet plus de transférer des fichiers énormes sans bouffer toute la mémoire (je suppose, je n'ai pas vérifié, il y a peut-être des bricolages dans l'algo).

          Ça ne résout pas ton soucis légitime :-)

          • [^] # Re: Tout se fait en même temps

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

            Un peu plus d'infos sur la question dans le man :

            -r, --recursive

       This tells rsync to copy directories recursively. See also
       --dirs (-d).

       Beginning with rsync 3.0.0, the recursive algorithm used
       is now an incremental scan that uses much less memory
       than before and begins the transfer after the scanning of
       the first few directories have been completed. This
       incremental scan only affects our recursion algorithm, and
       does not change a non-recursive transfer. It is also only
       possible when both ends of the transfer are at least
       version 3.0.0.

       Some options require rsync to know the full file list, so
       these options disable the incremental recursion mode.
       These include: --delete-before, --delete-after,
       --prune-empty-dirs, and --delay-updates. Because of this,
       the default delete mode when you specify --delete is now
       --delete-during when both ends of the connec‐ tion are at
       least 3.0.0 (use --del or --delete-during to request this
       improved deletion mode explicitly). See also the
       --delete-delay option that is a better choice than using
       --delete-after.

       Incremental recursion can be disabled using the
       --no-inc-recursive option or its shorter --no-i-r alias.

            • [^] # Re: Tout se fait en même temps

              Posté par  . Évalué à 2.

              Le changement que tu pointes est valable pour l'étape de transfert de la liste des fichiers. Avant ça prenait des plombes sur une grosse arborescence et tout était stocké en mémoire.

              Dans le cas ici, il ne transfert qu'un seul fichier. L'étape « sending incremental file list » est donc réduite au strict minimum.

  • # comment connaitre la difference

    Posté par  . Évalué à 4.

    tu ne peux decemment pas commencer l'envoi AVANT de savoir ce qu'il faut envoyer (le calcul de la difference)
    il te faut donc bien 2 etapes :
    - le calcul distant, recuperation des infos, extraction de ce qui pourrait avoir changé
    - l'envoi de la dite difference

    • [^] # Re: comment connaitre la difference

      Posté par  . Évalué à 2.

      La date est différente, donc de base il n'a pas besoin d'un checsum pour savoir si il faut resynchroniser. Où si il le fait quand même alors ma question est :
      Quel argument dois je passer pour lui dire qu'en cas de timestamp différent de synchroniser sans faire un checksum ?

      • [^] # Re: comment connaitre la difference

        Posté par  . Évalué à 3.

        D'après le man de rsync, par défaut, rsync se fonde sur la taille du fichier et sa date de dernière modification pour savoir s'il y a eu modification.
        Tu peux passer l'option --checksum pour forcer rsync à vérifier si les fichiers sont différents par un checksum, au lieu de la taille et de la date.

        Ensuite, si j'ai bien compris, l'algorithme de rsync découpe le fichier en morceau, fait des checksums pour chaque partie, permettant ainsi de ne transférer que les parties du fichier qui ont effectivement changé.
        Tu peux également passer l'option --whole-file pour forcer rsync à copier le fichier entièrement, sans utiliser cette méthode de découpage.

        • [^] # Re: comment connaitre la difference

          Posté par  . Évalué à 2.

          J'ai essayer ces 2 arguments. Pour --checksum, il check alors l'intégrité dans tous les cas, même si les dates sont identiques. Mon problème reste le même dans le sens où il test l'intégrité du fichier destination puis celui de source. Et toujours pas simultanément.

          Pour l'argument --whole-file, cela supprime le contrôle checksum, donc je n'est plus mon soucis. Cependant, il transfert l'intégralité via le réseau. Donc la solution ne répond plus au besoin de départ.

      • [^] # Re: comment connaitre la difference

        Posté par  . Évalué à 2.

        Ca fonctionne bien, puisqu'il synchronise l'image sans fichier temporaire et en n'envoyant via le réseau que la différence.

        je repose ma question,
        la date permet de savoir que le fichier a changé,
        mais comment savoir à quel endroit le fichier a changé…

        il faut donc bien que rsync calcule chaque portion de fichier, fasse les checksum, et compare local et distant,

        pour n'envoyer que la difference.

        l'interet ?
        ne pas renvoyer 500Go à chaque backup

        inconvenient
        il faut chercher ou est la difference

        sinon tu fais comme le propose l'ami en dessous,
        tu transfert tout le fichier (donc les 500Go), tu economises alors le temps de calcul des differences, mais tu perd le temps du transfert des 500Go là ou seulement 100Mo sont peut-etre necessaire et tu sature eventuellement ton reseau plus longtemp

        à toi donc de voir entre le temps CPU du calcul des checksum, et le temps de transfert/saturation reseau, ce qui est le plus critique pour toi

        • [^] # Re: comment connaitre la difference

          Posté par  . Évalué à 2.

          NeoX, je suis entièrement d'accord avec toi, c'est normal qu'il contrôle l'intégrité de tous les blocs du fichier afin de connaitre lequels sont à synchroniser. Donc oui le checksum est necessaire.

          Cependant, il calcul les checksum du fichier de destination puis et seulement après, il calcul les checksum du fichier source. Et là, c'est du temps perdu, s'il pouvait calculer les deux simultanément …

  • # alternatives a rsync

    Posté par  . Évalué à 2.

    il y en a de nombreuses, il me semble. On peut citer restic, borg. Il y en a bien d'autres. Ce sujet a été régulièrement abordé ici.

    Pour ce qui concerne restic, il maintient localement une table de hash et en principe, le site distant est en synchro avec la table de hash local. Il n'est pas nécessaire de calculer tous les blocs distants. Et cas de nécessité (perte de synchro), je suppose que cela peut se faire. De toute facon, restic maintient un ensemble de blocs sur le site d'archivage et non pas le fichier directement. Une session restic peut donc démarrer immédiatement après avoir calculé le hash localement. Il s'agit d'un hash partiel et par block de taille variable et non pas d'un hash sur l'ensemble du fichier.

    BTRFS possède aussi des fonctions de synchro entre 2 snapshots. Seul le différentiel est envoyé. Je ne sais pas comment se déroule la session (dialogue entre source et destination).

    • [^] # Re: alternatives a rsync

      Posté par  . Évalué à 2.

      Ne pas oublier que rsync remplace aussi avantageusement scp!

      «The scp protocol is outdated, inflexible and not readily fixed. We
      recommend the use of more modern protocols like sftp and rsync for
      file transfer instead.»

      À chacun sa méthode… :)

      alias scp="printf 'Please, use rsync instead\!\a\n'"

Suivre le flux des commentaires

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