Paralléliser rsync avec GNU Parallel

Les étapes suivantes ont fonctionné pour moi :

Exécuter le rsync --dry-run d'abord afin d'obtenir la liste des fichiers qui seraient concernés.

$ rsync -avzm --stats --safe-links --ignore-existing --dry-run \
    --human-readable /data/projects REMOTE-HOST:/data/ > /tmp/transfer.log

J'ai alimenté la sortie de cat transfer.log à parallel pour exécuter 5 rsync s en parallèle, comme suit :

$ cat /tmp/transfer.log | \
    parallel --will-cite -j 5 rsync -avzm --relative \
      --stats --safe-links --ignore-existing \
      --human-readable {} REMOTE-HOST:/data/ > result.log

Ici, --relative l'option (lien) garantit que la structure de répertoires pour les fichiers concernés, à la source et à la destination, reste la même (à l'intérieur de /data/ répertoire), la commande doit donc être exécutée dans le dossier source (par exemple, /data/projects ).

Personnellement, j'utilise celui-ci :

\ls -1 | parallel rsync -a {} /destination/directory/

Ce qui n'est utile que lorsque vous avez plus de quelques répertoires non presque vides, sinon vous finirez par avoir presque tous les rsync termine et le dernier fait tout le travail tout seul.

Notez la barre oblique inverse avant ls ce qui entraîne le saut des alias. Ainsi, en veillant à ce que la sortie soit comme vous le souhaitez.

Je déconseillerais fortement à quiconque d'utiliser la réponse acceptée, une meilleure solution consiste à explorer le répertoire de niveau supérieur et à lancer un nombre proportionnel d'opérations rync.

J'ai un gros volume zfs et ma source était un montage cifs. Les deux sont liés au 10G, et dans certains benchmarks peuvent saturer le lien. Les performances ont été évaluées à l'aide de zpool iostat 1 .

Le lecteur source a été monté comme :

mount -t cifs -o username=,password= //static_ip/70tb /mnt/Datahoarder_Mount/ -o vers=3.0

Utilisation d'un seul rsync processus :

rsync -h -v -r -P -t /mnt/Datahoarder_Mount/ /StoragePod

le compteur io indique :

StoragePod  30.0T   144T      0  1.61K      0   130M
StoragePod  30.0T   144T      0  1.61K      0   130M
StoragePod  30.0T   144T      0  1.62K      0   130M

Ceci dans les benchmarks synthétiques (disque cristal), les performances en écriture séquentielle approchent les 900 Mo/s ce qui signifie que le lien est saturé. 130 Mo/s, ce n'est pas très bon, et c'est la différence entre attendre un week-end et deux semaines.

J'ai donc créé la liste des fichiers et essayé de relancer la synchronisation (j'ai une machine à 64 cœurs) :

cat /home/misha/Desktop/rsync_logs_syncs/Datahoarder_Mount.log | parallel --will-cite -j 16 rsync -avzm --relative --stats --safe-links --size-only --human-readable {} /StoragePod/ > /home/misha/Desktop/rsync_logs_syncs/Datahoarder_Mount_result.log

et il avait les mêmes performances !

StoragePod  29.9T   144T      0  1.63K      0   130M
StoragePod  29.9T   144T      0  1.62K      0   130M
StoragePod  29.9T   144T      0  1.56K      0   129M

Comme alternative, j'ai simplement exécuté rsync sur les dossiers racine :

rsync -h -v -r -P -t /mnt/Datahoarder_Mount/Mikhail/Marcello_zinc_bone /StoragePod/Marcello_zinc_bone
rsync -h -v -r -P -t /mnt/Datahoarder_Mount/Mikhail/fibroblast_growth /StoragePod/fibroblast_growth
rsync -h -v -r -P -t /mnt/Datahoarder_Mount/Mikhail/QDIC /StoragePod/QDIC
rsync -h -v -r -P -t /mnt/Datahoarder_Mount/Mikhail/sexy_dps_cell /StoragePod/sexy_dps_cell

Cela a en fait amélioré les performances :

StoragePod  30.1T   144T     13  3.66K   112K   343M
StoragePod  30.1T   144T     24  5.11K   184K   469M
StoragePod  30.1T   144T     25  4.30K   196K   373M

En conclusion, comme @Sandip Bhattacharya l'a évoqué, écrivez un petit script pour obtenir les répertoires et le mettre en parallèle. Sinon, passez une liste de fichiers à rsync. Mais ne créez pas de nouvelles instances pour chaque fichier.