Reprise partielle de rsync (-P / – partial) lors d’un transfert interrompu

TL; DR : Utilisez --timeout=X (X en secondes) pour modifier le délai d’expiration du serveur rsync par défaut, et non --inplace .

Le problème est que les processus du serveur rsync (dont il y en a deux, voir rsync --server ... dans la sortie ps du récepteur) continuent de fonctionner, pour attendre que le client rsync envoie des données.

Si les processus du serveur rsync ne reçoivent pas les données pendant un temps suffisant, ils expirent, se terminent et nettoient en déplaçant le fichier temporaire vers son nom “propre” (par exemple, aucun suffixe temporaire). Vous pourrez alors reprendre.

Si vous ne souhaitez pas attendre le délai d’expiration par défaut trop long pour que le serveur rsync se ferme automatiquement, connectez-vous au serveur une fois la connexion Internet rétablie et nettoyez les processus du serveur rsync manuellement. Cependant, vous devez terminer poliment rsync – sinon, le fichier partiel ne sera pas mis en place; mais plutôt le supprimer (et donc il n’y a pas de fichier à reprendre). Pour demander poliment à rsync de se terminer, ne pas SIGKILL (par exemple, -9 ), mais SIGTERM (par exemple, pkill -TERM -x rsync – seulement un exemple, vous devez faire attention à ne faire correspondre que les processus rsync concernés avec votre client).

Heureusement, il existe un moyen plus simple: utiliser l’ --timeout=X (X en secondes); Il est également transmis aux processus du serveur rsync.

Par exemple, si vous spécifiez rsync ... --timeout=15 ... , les processus rsync client et serveur quitteront proprement s’ils n’envoient / reçoivent pas de données en 15 secondes. Sur le serveur, cela signifie déplacer le fichier temporaire en position, prêt à reprendre.

Je ne suis pas sûr de la valeur de délai d’attente par défaut des différents processus rsync qui essaieront d’envoyer / recevoir des données avant qu’elles ne meurent (cela peut varier avec le système d’exploitation). Lors de mes tests, les processus rsync du serveur continuent à fonctionner plus longtemps que le client local. Sur une connexion réseau “morte”, le client se termine avec un tuyau cassé (par exemple, pas de socket réseau) après environ 30 secondes; vous pouvez expérimenter ou revoir le code source. Cela signifie que vous pouvez essayer de “passer” la mauvaise connexion Internet pendant 15 à 20 secondes.

Si vous ne nettoyez pas les processus rsync du serveur (ou attendez qu’ils meurent), mais lancez immédiatement un autre processus client rsync, deux processus serveur supplémentaires seront lancés (à l’autre extrémité du processus de votre nouveau client). Plus précisément, le nouveau client rsync ne réutilisera / ne se reconnectera pas aux processus de serveur rsync existants. Ainsi, vous aurez deux fichiers temporaires (et quatre processus de serveur rsync) – cependant, seul le deuxième fichier temporaire plus récent contient de nouvelles données (reçues de votre nouveau processus client rsync).

Fait intéressant, si vous nettoyez ensuite tous les processus du serveur rsync (par exemple, arrêtez votre client qui arrête les nouveaux serveurs rsync, puis SIGTERM des anciens serveurs rsync, il semble fusionner tous les fichiers partiels dans le nouveau fichier nommé approprié). Donc, imaginez une copie partielle longue durée qui meurt (et vous pensez avoir “perdu” toutes les données copiées), et une courte relance rsync (oops!) Relancée .. vous pouvez arrêter le deuxième client, SIGTERM le premiers serveurs, il va fusionner les données, et vous pouvez reprendre.

Enfin, quelques brèves remarques:

• Ne pas utiliser --inplace pour contourner ce --inplace . Vous aurez sans doute d’autres problèmes à la suite, renseignez-vous pour les détails.
• C’est sortingvial, mais -t dans vos options rsync est redondant, il est impliqué par -a .
• Une image disque déjà compressée envoyée via rsync sans compression peut entraîner une réduction du temps de transfert (en évitant une double compression). Cependant, je ne suis pas sûr des techniques de compression dans les deux cas. Je le testerais
• Si je comprends --checksum – --checksum / -c , cela ne vous aidera pas dans ce cas. Cela affecte la manière dont rsync décide de transférer un fichier. Cependant, une fois la première synchronisation terminée, vous pouvez exécuter une deuxième synchronisation avec -c pour insister sur les sums de contrôle, afin d’éviter que le format et la taille du fichier soient identiques des deux côtés, mais que des données incorrectes soient écrites.

Désolé mais les autres réponses sont trop compliquées: -7. Une réponse plus simple pour moi: (avec rsync over -e ssh)

 # optionally move rsync temp file, then resume using rsync dst$ mv ..6FuChr  src$ rsync -avhzP --bwlimit=1000 -e ssh  :/ 

Fonctionne également lors de la reprise d’un scp qui a été interrompu.

Rsync crée un fichier temporaire … Le fichier temporaire se développe rapidement en taille de fichier partiellement transféré. CV de transfert.

Scp écrit dans le fichier de destination finale. Si le transfert est interrompu, il s’agit d’un fichier tronqué.

Explication des arguments:

-avhz .. h = humanoid, v = verbose, a = archive, z = compression .. archive lui demande de maintenir les valeurs time_t donc même si les horloges sont sorties, rsync connaît la date réelle de chaque fichier

-P est l’abréviation de –partial –progress. –partial demande à rsync de conserver les fichiers partiellement transférés (et lors de la reprise, rsync utilisera toujours les fichiers partiellement transférés après avoir effectué une sum de contrôle en toute sécurité)

À partir des pages de manuel: http://ss64.com/bash/rsync_options.html

 --partial By default, rsync will delete any partially transferred file if the transfer is interrupted. In some circumstances it is more desirable to keep partially transferred files. Using the --partial option tells rsync to keep the partial file which should make a subsequent transfer of the rest of the file much faster. --progress This option tells rsync to print information showing the progress of the transfer. This gives a bored user something to watch. This option is normally combined with -v. Using this option without the -v option will produce weird results on your display. -P The -P option is equivalent to --partial --progress. I found myself typing that combination quite often so I created an option to make it easier. 

REMARQUE: pour une connexion interrompue plusieurs fois: Si vous devez reprendre après la synchronisation (une fois la connexion interrompue), il est préférable de renommer le fichier temporaire sur la destination. scp crée un fichier sur la destination avec le même nom que le fichier final. Si scp est interrompu, ce fichier est une version tronquée du fichier. Un rsync (-avzhP) reprendra de ce fichier mais commencera à écrire sur un nom de fichier temporaire tel que ..Yhg7al.

Procédure en commençant par scp:

 scp; *interrupt*; rsync; [REPEAT_as_needed: *interrupt*; mv .destfile.tmpzhX destfile; rsync;]. 

Procédure lors du démarrage avec rsync:

 rsync; [REPEAT_as_needed: *interrupt*; mv .destfile.tmpzhX destfile; rsync;]. 

J’ai trouvé que l’ajout de –inplace le corrige. Pas sûr de savoir comment –partial est censé fonctionner sans elle mais il a repris mes transferts. Mes fichiers sont quand même assez gros et je me demande si je vais me retrouver avec des fichiers corrompus si un transfert commence et des heures plus tard, un autre transfert démarre mais voit un fichier incomplet et ne sait pas qu’il est en train d’être téléchargé. il. Quelqu’un sait? Peut-être un script bash pour enregistrer l’identifiant du processus en cours et ne pas lancer un autre transfert?

Si vous craignez des fichiers corrompus après un résumé, vous pouvez append --checksum pour le forcer à effectuer un total de contrôle sur l’ensemble du fichier à chaque fois. En effet, cela vous coûtera des cycles disque-IO et CPU, mais seulement une légère surcharge du réseau.