Paralelice rsync usando GNU Parallel

Los siguientes pasos hicieron el trabajo por mí:

1. Ejecute el rsync --dry-run primero para obtener la lista de archivos que se verían afectados.

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

1. Ingresé la salida de cat transfer.log a parallel para ejecutar 5 rsync s en paralelo, de la siguiente manera:

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

Aquí, --relative opción (enlace) aseguró que la estructura del directorio para los archivos afectados, en el origen y el destino, sigue siendo el mismo (dentro de /data/ directorio), por lo que el comando debe ejecutarse en la carpeta de origen (por ejemplo, /data/projects ).

Yo personalmente uso este sencillo:

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

Lo cual solo es útil cuando tiene más de unos pocos directorios que no están casi vacíos; de lo contrario, terminará teniendo casi todos los rsync terminando y el último haciendo todo el trabajo solo.

Tenga en cuenta la barra invertida antes de ls lo que hace que se salten los alias. Por lo tanto, asegurando que la salida sea la deseada.

Desaconsejaría encarecidamente a cualquiera que use la respuesta aceptada, una mejor solución es rastrear el directorio de nivel superior e iniciar una cantidad proporcional de operaciones rync.

Tengo un gran volumen zfs y mi fuente fue un montaje cifs. Ambos están enlazados con 10G, y en algunos benchmarks pueden saturar el enlace. El rendimiento se evaluó usando zpool iostat 1 .

La unidad de origen se montó como:

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

Usando un único rsync proceso:

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

el medidor de io lee:

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

Esto en puntos de referencia sintéticos (disco de cristal), el rendimiento para la escritura secuencial se acerca a los 900 MB/s, lo que significa que el enlace está saturado. 130MB/s no es muy bueno, y la diferencia entre esperar un fin de semana y dos semanas.

Entonces, construí la lista de archivos e intenté ejecutar la sincronización nuevamente (tengo una máquina de 64 núcleos):

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

¡y tuvo el mismo rendimiento!

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

Como alternativa, simplemente ejecuté rsync en las carpetas raíz:

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

Esto realmente mejoró el rendimiento:

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 conclusión, como mencionó @Sandip Bhattacharya, escriba un pequeño script para obtener los directorios y hacer un paralelo con eso. Alternativamente, pase una lista de archivos a rsync. Pero no cree nuevas instancias para cada archivo.