Comment accélérer rsync ?

Évitez

• -z / --compress La compression ne fait que charger le processeur car le transfert ne se fait pas sur un réseau mais sur la RAM.
• --append-verify : reprendre un transfert interrompu. Cela semble être une bonne idée, mais il y a un cas d'échec dangereux : tout fichier de destination de la même taille (ou plus) que la source sera IGNORÉ. De plus, elle fait la somme de contrôle de tout le fichier à la fin, ce qui signifie qu'il n'y a pas d'augmentation significative de la vitesse de transfert par rapport à celle de la source. --no-whole-file tout en ajoutant un cas d'échec dangereux.

Utilisez

• -S / --sparse : transformer des séquences de nuls en blocs épars
• --partial ou -P qui est --partial --progress : sauvegarder tout fichier partiellement transféré pour une reprise ultérieure. Note : les fichiers n'auront pas de nom temporaire, donc assurez-vous que rien d'autre ne s'attend à utiliser la destination jusqu'à ce que la copie complète soit terminée.
• --no-whole-file de sorte que tout ce qui doit être renvoyé utilise le transfert delta. La lecture de la moitié d'un fichier partiellement transféré est souvent beaucoup plus rapide que sa réécriture.
• --inplace pour éviter la copie de fichiers (mais seulement si rien ne lit la destination jusqu'à ce que le transfert complet soit terminé)

Vous ne dites pas quelle est la distribution de taille de vos fichiers. S'il y a beaucoup de petits fichiers, cela réduira le taux de transfert global en augmentant la latence du mouvement de la tête dans les lecteurs source et de destination, car l'outil ouvre de nouveaux fichiers et le système d'exploitation maintient les entrées de répertoire et d'autres métadonnées (comme le journal du système de fichiers si vous utilisez la journalisation des métadonnées comme ext3/ext4 et NTFS le font par défaut) à jour pendant le transfert. Un processus de copie de fichiers ne se met en marche que pour les objets plus volumineux, lors d'un simple transfert en masse.

J'ai trouvé ceci comme réponse

https://gist.github.com/KartikTalwar/4393116

rsync -aHAXxv --numeric-ids  --progress -e 'ssh -T -c aes128-gcm@openssh.com -o Compression=no -x ' <source_dir> user@<host>:<dest_dir>

Voici quelques explications concernant les interrupteurs

rsync (tout le monde semble aimer -z, mais c'est beaucoup plus lent pour moi)

a: archive mode - rescursive, preserves owner, preserves permissions, preserves modification times, preserves group, copies symlinks as symlinks, preserves device files.
H: preserves hard-links
A: preserves ACLs
X: preserves extended attributes
x: don't cross file-system boundaries
v: increase verbosity
--numeric-ds: don't map uid/gid values by user/group name
--progress: show progress during transfer

ssh

T: turn off pseudo-tty to decrease cpu load on destination.
c aes128-gcm@openssh.com: use the weakest but fastest SSH encryption.
o Compression=no: Turn off SSH compression.
x: turn off X forwarding if it is on by default.

Je n'ai aucune raison de penser que rsync est le coupable de cette lenteur.

Je soupçonne que le lecteur lui-même ou son système de fichiers est en cause.

En fait, quelques facteurs laissent entrevoir une cause possible. Vous mentionnez qu'il s'agit d'une clé USB et que vous transférez 150 Go en une seule fois. Je suppose que votre clé USB utilise le système SMR (Shingled Magnetic Recording).

Les lecteurs SMR chevauchent les pistes de telle sorte que la lecture s'effectue normalement, mais chaque écriture sur le lecteur, puisqu'elle écrase également les pistes voisines, exige que le lecteur réécrive une partie importante du disque, et l'écriture est lente. Le miracle, c'est que ces disques fonctionnent normalement la plupart du temps, car le disque remappe les écritures dans une zone de stockage temporaire qui n'utilise pas le SMR, puis les réécrit sur le disque plus tard en arrière-plan. Mais cette zone de stockage n'a qu'une taille de quelques Go, donc pour tout transfert continu de plus de 10 Go, par exemple, la vitesse d'écriture chute de façon spectaculaire à environ 5 Mo/s. Si vous arrêtez d'écrire sur le disque et que vous le laissez tourner au ralenti pendant environ 10 minutes, ses performances reviendront à la normale car il aura eu le temps de vider sa zone d'attente temporaire, mais elles chuteront à nouveau si vous effectuez une autre écriture continue de plusieurs Go.

Malgré certains commentaires contraires, rsync est agréable et rapide lorsqu'il fonctionne localement, en modifiant sa configuration en conséquence. En fonctionnement local, rsync n'utilise pas de transfert delta. Et, puisque la compression du transfert n'a pas de sens quand il s'agit essentiellement d'un tuyau local, je doute que l'option -z a un quelconque effet, bien que la documentation ne le précise pas. Même si c'est le cas, il ne devrait pas limiter la vitesse à <5MB/s, puisque sa compression est capable de plusieurs fois cette vitesse.

Et, --inplace n'affecte le comportement de rsync que lorsque le fichier existe à la destination et que seule une partie du fichier doit être mise à jour. Puisque le transfert delta est désactivé lorsque rsync fonctionne en local, je pense qu'il ne devrait avoir aucun effet.

Évitez d'utiliser le -v, --verbose sauf en cas de débogage. Surtout quand on redirige la sortie vers un fichier. Dans mon cas, l'exécution de rsync avec l'option -v était 8x plus lent que de le laisser fonctionner silencieusement. Pensez à utiliser le --log-file à la place.