rsync via VPN : une nouvelle tentative qui réutilise le transfert interrompu

Votre envoi se bloque à quatre gigaoctets d’une archive de douze gigaoctets, et l’habitude héritée des gestionnaires de téléchargement dit d’appuyer sur reprendre. rsync ne reprendra pas le flux TCP, car ce flux a disparu avec la dernière retransmission du tunnel. Ce qu’il peut faire, c’est conserver les octets déjà reçus et s’en servir de base pour la tentative suivante, ce qui est un autre mécanisme avec un autre ensemble de règles. Les options que vous choisissez décident si cette réutilisation a lieu du tout.

La nouvelle tentative reconstruit l’état, elle ne reprend pas le flux

Quand la session SSH tombe, il ne reste à l’extrémité distante que ce qu’elle a réussi à écrire sur le disque, et rien d’autre. Il n’y a pas de jeton de session auquel se raccrocher ni de numéro de séquence à rejouer. L’exécution suivante ouvre une nouvelle connexion, relit la source et demande au destinataire ce qu’il possède déjà.

C’est cette dernière question qui explique pourquoi un fichier partiel vaut la peine d’être conservé. La copie du destinataire donne à rsync de quoi comparer, et l’algorithme n’envoie que les différences qu’il peut identifier. Il s’agit toujours d’un nouveau transfert de métadonnées et d’une nouvelle passe sur la source, donc le temps gagné est proportionnel à la part du fichier qui correspond, non à la distance atteinte par la connexion précédente. Si le destinataire n’a rien conservé, la tentative suivante est une copie complète, quel que soit le nombre de gigaoctets déplacés par la première.

Décidez où vit le fragment réutilisable

Le comportement par défaut écrit le fichier partiel au chemin de destination, ce qui rend une archive à moitié écrite visible sous le nom final. --partial-dir le déplace dans un répertoire de votre choix, et le manuel décrit ce répertoire comme conservé pour être utilisé comme données par un transfert ultérieur. Un nom relatif est résolu sous le répertoire de destination, ce qui est exactement ce que vous voulez quand les deux extrémités peuvent avoir des dispositions différentes.

rsync -e ssh --partial-dir=.rsync-partial --info=progress2 -- \
  large-archive.bin [email protected]:/srv/incoming/

L’ordre compte aussi à la destination : le répertoire partiel a besoin de place pour le fragment, et le volume a besoin de place pour le fichier terminé également. Remplir le volume cible au milieu du transfert produit un échec qui ressemble à un problème réseau sans en être un, et peut laisser le fragment conservé tronqué. Vérifiez l’espace libre sur l’hôte destinataire avant le début de l’exécution, pas après qu’elle a échoué. Quelques secondes avec df -h sur le même chemin SSH sont le test le moins coûteux possible du plan.

Les permissions sont une inquiétude plus petite mais réelle. Un répertoire partiel où des comptes non concernés peuvent écrire permet à quelqu’un d’autre de substituer du contenu que votre prochaine exécution traitera comme déjà reçu. Gardez-le la propriété du compte de transfert et ne le placez pas là où d’autres services publient.

Lancez la même copie, pas une copie plus astucieuse

La réutilisation ne s’applique que si la source et la destination décrivent encore le même objet. Même chemin, même nom, même fichier. Renommer la source ou pointer vers un autre répertoire de destination entame une nouvelle comparaison contre rien d’utile.

N’ajoutez pas --whole-file en attendant le comportement delta. Cette option demande à rsync de copier le fichier entier sans la comparaison de somme de contrôle glissante, ce qui est un choix raisonnable sur une liaison locale rapide et exactement le mauvais après un envoi longue distance échoué. --inplace change aussi l’histoire : il écrit directement dans le fichier de destination, si bien qu’une interruption laisse un fichier qui mélange ancien et nouveau contenu sans fragment séparé sur lequel se rabattre.

La ligne de progression rapporte la progression globale du transfert. Ce n’est pas un signal d’achèvement. Un nombre qui atteint cent pour cent alors que la connexion est encore ouverte signifie que les données ont été poussées, non que le destinataire a renommé, synchronisé ou accepté quoi que ce soit.

N’acceptez l’objet qu’une fois qu’il correspond

Confirmez d’abord le code de sortie, puis comparez le résultat plutôt que de vous fier à l’absence d’erreurs. Un contrôle de taille attrape la plupart des transferts tronqués ; une comparaison de sommes de contrôle attrape le reste, et les deux coûtent peu face à une nouvelle exécution de l’envoi.

Si l’archive est publiée par un processus en aval, faites attendre à ce processus le fichier accepté. Un fragment conservé qui atterrit dans un répertoire surveillé sous le nom final est ramassé par le prochain balayage, et l’erreur du consommateur portera sur une entrée corrompue plutôt que sur un transfert qui ne s’est jamais terminé.

Laissez la source tranquille jusqu’à ce que le destinataire confirme. Régénérer l’archive entre les tentatives change la base de comparaison, et l’exécution suivante soit transfère presque tout, soit produit un fichier qui ne correspond ni à l’ancienne ni à la nouvelle source.

Quand la limite est la liaison, pas l’option

La surcharge d’en-tête et de protocole est un coût d’un transfert, et c’est rarement celui qui décide de la durée d’un gros fichier. Le comportement de redémarrage compte davantage : une méthode qui survit à une coupure sans étapes manuelles livre un fichier utilisable plus tôt qu’une méthode plus rapide qui doit repartir de zéro. Le stockage aux deux extrémités et le chemin d’authentification appartiennent à la même comparaison.

Comparez les chemins alternatifs autorisés avec le même fichier et la même destination, et notez d’où chacun repart après une interruption. Cette seule colonne vous en dit plus sur un envoi de douze gigaoctets via un VPN que n’importe quel débit de pointe mesuré lors d’un test court.