Reprise de la rsync partielle (- p / --partielle) sur un transfert interrompu
j'essaie de sauvegarder mon serveur de fichiers sur un serveur de fichiers supprimer en utilisant rsync. Le Rsync ne reprend pas avec succès lorsqu'un transfert est interrompu. J'ai utilisé l'option partielle mais rsync ne trouve pas le fichier qu'il a déjà commencé parce qu'il le renomme en un fichier temporaire et lorsqu'il est repris il crée un nouveau fichier et commence dès le début.
Voici ma commande:
rsync -avztP -e "ssh -p 2222" /volume1/ myaccont@backup-server-1:/home/myaccount/backup/ --exclude "@spool" --exclude "@tmp"
lorsque cette commande est exécutée, un fichier de sauvegarde nommé OldDisk.dmg à partir de mon machine locale créé sur la machine distante comme quelque chose comme .OldDisk.DMG.SjDndj23.
Maintenant, quand la connexion internet est interrompu et je dois reprendre le transfert, je dois trouver où rsync laissé par trouver le fichier temp .OldDisk.DMG.SjDndj23 et le renommer OldDisk.dmg afin qu'il voit, il existe déjà un fichier qu'il peut reprendre.
Comment puis-je corriger cela pour ne pas avoir à intervenir manuellement chaque de temps?
4 réponses
TL;DR: Utiliser --timeout=X (X en secondes) pour changer le délai d'attente par défaut du serveur rsync, pas --inplace.
Le problème est le serveur rsync processus qui sont au nombre de deux, voir rsync --server ...ps sortie sur le récepteur) continuer à tourner, pour attendre que le client rsync envoie les données.
si les processus du serveur rsync ne reçoivent pas les données pendant un temps suffisant, ils vont en effet temporiser, s'auto-terminer et nettoyer en déplaçant le fichier temporaire vers nom "propre" (p. ex. pas de suffixe temporaire). Vous serez alors en mesure de reprendre.
si vous ne voulez pas attendre le long délai par défaut pour que le serveur rsync se termine automatiquement, alors lorsque votre connexion internet revient, connectez-vous au serveur et nettoyez les processus du serveur rsync manuellement. Cependant, vous doit se terminer poliment rsync -- sinon, il ne déplacera pas le fichier partiel à l'endroit; mais plutôt, le supprimer (et donc il n'y a pas de fichier à reprendre). De demandez poliment à rsync de terminer, ne pas SIGKILL (e.g.,-9), mais SIGTERM (e.g.,pkill -TERM -x rsync - seulement un exemple, vous devriez prendre soin de faire correspondre seulement les processus rsync concernés avec votre client).
heureusement il y a un moyen plus facile: utilisez le --timeout=X (X en secondes) option; elle est transmise aux processus du serveur rsync.
Par exemple, si vous spécifiez rsync ... --timeout=15 ..., les processus rsync du client et du serveur se termineront proprement s'ils n'envoient pas / ne reçoivent pas de données dans 15 secondes. Sur le serveur, cela signifie mettre le fichier temporaire en position, prêt pour la reprise.
Je ne suis pas sûr de la valeur de délai par défaut des différents processus rsync va essayer d'envoyer/recevoir des données avant leur mort (il pourrait varier avec le système d'exploitation). Dans mes tests, les processus rsync du serveur restent plus longs que le client local. Sur une connexion réseau "morte", le client se termine avec un tuyau cassé (par exemple, pas de prise réseau) après environ 30 secondes; vous pourrait expérimenter ou revoir le code source. Ce qui veut dire que vous pourriez essayer de "contourner" 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 supplémentaires du serveur seront lancés (pour l'autre extrémité de votre nouveau processus client). Plus précisément, le nouveau client rsync ne réutiliser/reconnecter avec les processus de serveur rsync existants. Ainsi, vous aurez deux fichiers temporaires (et quatre processus du serveur rsync) -- bien que seul le second fichier temporaire le plus récent ait de nouvelles données écrites (reçues de votre nouveau processus client rsync).
fait intéressant, si vous nettoyez alors tous les processus du serveur rsync (par exemple, arrêtez votre client qui arrêtera les nouveaux serveurs rsync, puis SIGTERM les anciens serveurs rsync, il semble fusionner (assembler) tous les fichiers partiels dans le nouveau fichier correct nommé. Alors, imaginez une longue course copie partielle qui meurt( et vous pensez que vous avez "perdu" toutes les données copiées), et un court lancement relancé rsync (oops!).. vous pouvez arrêter le deuxième client, SIGTERM les premiers serveurs, il va fusionner les données, et vous pouvez reprendre.
Enfin, quelques remarques:
- Ne pas utiliser
--inplacepour contourner ce problème. Vous aurez sans doute d'autres problèmes en conséquence,man rsyncpour les détails. - C'est trivial, mais
-tdans vos options rsync est redondant, il est sous-entendu par-a. - déjà compressé l'image du disque envoyé par rsync sans la compression peut réduire le temps de transfert (en évitant la double compression). Cependant, je ne suis pas sûr des techniques de compression dans les deux cas. J'aimerais le tester.
- autant que je sache
--checksum/-c, cela ne vous aidera pas dans ce cas. Il affecte la façon dont rsync décide si elle devrait transfert d'un fichier. Cependant, après un premier rsync complète, vous pourriez exécuter un deuxième rsync avec-cpour insister sur les checksums, pour empêcher l'étrange cas que la taille du fichier et le modtime sont les mêmes des deux côtés, mais les mauvaises données ont été écrites.
désolé mais les autres réponses ici sont trop compliquées :-7. Une réponse plus simple travaillant pour moi: (en utilisant rsync over-e ssh)
# optionally move rsync temp file, then resume using rsync
dst$ mv .<filename>.6FuChr <filename>
src$ rsync -avhzP --bwlimit=1000 -e ssh <fromfiles> <user@somewhere>:<destdir>/
fonctionne également lors de la reprise d'un scp qui a été interrompu.
Rsync crée un fichier temporaire ... Le fichier temporaire croît rapidement à la taille du fichier partiellement transféré. Le transfert reprend.
Scp écrit dans le fichier de destination finale. Si le transfert est interrompu, c'est un tronc de fichier.
Explication de la args:
- avhz .. h=humanoïde, v=verbose, - un=archive, z=compression .. archive lui demande de maintenir les valeurs de time_t donc même si les horloges sont dehors rsync connaît la date vraie de chaque fichier
-P est l'abréviation de --partielle, des progrès. -- partial dit à rsync de conserver les fichiers partiellement transférés (et à la reprise rsync utilisera les fichiers partiellement transférés toujours après checksumming en toute sécurité)
De l'homme page: 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 fois que la connexion est interrompue plusieurs fois: Si vous devez reprendre après rsync (après l'interruption de la connexion), alors il est préférable de renommer le fichier temporaire sur 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 à partir de ce fichier mais commencera à écrire pour un nom de fichier temporaire comme ..Yhg7al.
Procédure de départ auprès de la scp:
scp; *interrupt*; rsync; [REPEAT_as_needed: *interrupt*; mv .destfile.tmpzhX destfile; rsync;].
Procédure de départ avec rsync:
rsync; [REPEAT_as_needed: *interrupt*; mv .destfile.tmpzhX destfile; rsync;].
j'ai trouvé que l'ajout de --en place des correctifs. Je ne sais pas comment --partial est censé fonctionner sans lui mais il a repris mes transferts. Mes fichiers sont encore assez gros cependant et je me demande si je vais finir avec des fichiers corrompus si un transfert commence et des heures plus tard un autre transfert commence mais voit un fichier incomplet et ne sait pas son actuellement en cours de téléchargement qui commence alors à ajouter des octets à elle. Tout le monde sait? Peut-être un bash scripting pour enregistrer l'identifiant du processus en cours et ne pas en Démarrer un autre. transfert?
si vous avez peur de fichiers corrompus après un CV, vous pouvez ajouter --checksum pour le forcer à faire de somme de contrôle sur l'ensemble du dossier à chaque fois. En effet, il vous coûtera quelques cycles disk-IO et CPU, mais seulement un léger frais généraux de réseau.