it-swarm.com.de

Rsync partiell (-P/- partiell) bei unterbrochener Übertragung fortsetzen

Ich versuche, meinen Dateiserver mit rsync auf einem entfernten Dateiserver zu sichern. Rsync wird nicht erfolgreich fortgesetzt, wenn eine Übertragung unterbrochen wird. Ich habe die partielle Option verwendet, aber rsync kann die bereits gestartete Datei nicht finden, weil sie in eine temporäre Datei umbenannt wird. Wenn sie fortgesetzt wird, erstellt sie eine neue Datei und beginnt am Anfang.

Hier ist mein Befehl:

rsync -avztP -e "ssh -p 2222" /volume1/ [email protected]:/home/myaccount/backup/ --exclude "@spool" --exclude "@tmp"

Wenn dieser Befehl ausgeführt wird, wird eine Sicherungsdatei mit dem Namen OldDisk.dmg von meinem lokalen Computer auf dem fernen Computer als etwas wie .OldDisk.dmg.SjDndj23 erstellt.

Wenn nun die Internetverbindung unterbrochen wird und ich die Übertragung fortsetzen muss, muss ich feststellen, wo rsync aufgehört hat, indem ich die temporäre Datei wie .OldDisk.dmg.SjDndj23 finde und sie in OldDisk.dmg umbenenne. so dass es dort bereits eine Datei gibt, die es wieder aufnehmen kann.

Wie kann ich das beheben, damit ich nicht jedes Mal manuell eingreifen muss?

21
Glitches

TL; DR : Verwenden Sie --timeout=X (X in Sekunden), um das Standard-Timeout für den rsync-Server zu ändern, nicht --inplace.

Das Problem besteht darin, dass die rsync-Serverprozesse (von denen es zwei gibt, siehe rsync --server ... in ps Ausgabe auf dem Empfänger) weiterhin ausgeführt werden, um darauf zu warten, dass der rsync-Client Daten sendet.

Wenn die rsync-Server-Prozesse für eine ausreichende Zeit keine Daten empfangen, tritt tatsächlich eine Zeitüberschreitung auf, sie werden automatisch beendet und bereinigt, indem die temporäre Datei auf ihren "richtigen" Namen verschoben wird (z. B. kein temporäres Suffix). Sie können dann fortfahren.

Wenn Sie nicht auf das lange Standardzeitlimit warten möchten, durch das der rsync-Server automatisch beendet wird, melden Sie sich beim Zurückkehren Ihrer Internetverbindung beim Server an und bereinigen Sie die rsync-Serverprozesse manuell. Sie müssen jedoch höflich beenden rsync - andernfalls wird die Teildatei nicht verschoben. sondern löschen Sie es (und somit gibt es keine Datei zum Fortsetzen). Wenn Sie rsync höflich zum Beenden auffordern möchten, verwenden Sie nicht SIGKILL (z. B. -9), sondern SIGTERM (z. B. pkill -TERM -x rsync - nur ein Beispiel, bei dem Sie darauf achten sollten, dass nur Übereinstimmungen gefunden werden die mit Ihrem Client verbundenen rsync-Prozesse).

Glücklicherweise gibt es einen einfacheren Weg: Verwenden Sie die Option --timeout=X (X in Sekunden); es wird auch an die Prozesse des rsync-Servers übergeben.

Wenn Sie beispielsweise rsync ... --timeout=15 ... angeben, werden sowohl der Client- als auch der Server-Rsync-Prozess ordnungsgemäß beendet, wenn sie innerhalb von 15 Sekunden keine Daten senden/empfangen. Auf dem Server bedeutet dies, dass die temporäre Datei in die Position gebracht wird, in der sie fortgesetzt werden kann.

Ich bin mir nicht sicher, ob der Standard-Timeout-Wert der verschiedenen rsync-Prozesse versucht, Daten zu senden/empfangen, bevor sie abstürzen (dies kann je nach Betriebssystem variieren). In meinen Tests werden die Server-Rsync-Prozesse länger ausgeführt als der lokale Client. Bei einer "toten" Netzwerkverbindung wird der Client nach etwa 30 Sekunden mit einer unterbrochenen Leitung (z. B. ohne Netzwerk-Socket) beendet. Sie können den Quellcode testen oder überprüfen. Das heißt, Sie könnten versuchen, die schlechte Internetverbindung für 15-20 Sekunden zu "beseitigen".

Wenn Sie die Server-Rsync-Prozesse nicht bereinigen (oder warten, bis sie abstürzen), sondern sofort einen anderen Rsync-Client-Prozess starten, werden zwei zusätzliche Server-Prozesse gestartet (für das andere Ende Ihres neuen Client-Prozesses). Insbesondere wird der neue rsync-Client die bestehenden rsync-Serverprozesse nicht wiederverwenden/erneut verbinden. Auf diese Weise verfügen Sie über zwei temporäre Dateien (und vier rsync-Serverprozesse). Es werden jedoch nur für die neuere, zweite temporäre Datei neue Daten geschrieben (die von Ihrem neuen rsync-Clientprozess empfangen wurden).

Wenn Sie dann alle rsync-Serverprozesse bereinigen (z. B. Ihren Client stoppen, wodurch die neuen rsync-Server gestoppt werden, dann SIGTERM die älteren rsync-Server), werden anscheinend alle Teildateien mit dem zusammengeführt (zusammengefügt) Stellen Sie sich also eine lange laufende Teilkopie vor, die stirbt (und Sie denken, Sie haben alle kopierten Daten "verloren"), und eine kurze laufende, neu gestartete rsync-Datei (oops!). Sie können die zweite stoppen Client, SIGTERM die ersten Server, werden die Daten zusammengeführt, und Sie können fortfahren.

Zum Schluss noch ein paar kurze Bemerkungen:

  • Verwenden Sie --inplace nicht, um dies zu umgehen. Sie werden zweifellos andere Probleme als Ergebnis haben, man rsync für die Details.
  • Es ist trivial, aber -t in Ihren rsync-Optionen ist redundant. Dies wird durch -a impliziert.
  • Ein bereits komprimiertes Disk-Image, das über rsync ohne Komprimierung gesendet wird, kann zu einer kürzeren Übertragungszeit führen (indem doppelte Komprimierung vermieden wird). Allerdings bin ich mir in beiden Fällen der Komprimierungstechniken nicht sicher. Ich würde es testen.
  • Soweit ich --checksum/-c verstehe, hilft es Ihnen in diesem Fall nicht weiter. Es beeinflusst, wie rsync entscheidet, ob eine Datei übertragen soll . Nach Abschluss eines ersten rsync-Vorgangs können Sie einen zweiten rsync-Vorgang mit -c ausführen, um auf Prüfsummen zu bestehen und den seltsamen Fall zu vermeiden, dass Dateigröße und Modtime identisch sind auf beiden seiten wurden aber schlechte daten geschrieben.
25
Richard Michael

Sorry, aber die anderen Antworten sind zu kompliziert: -7 ... Eine einfachere Antwort, die für mich funktioniert: (mit 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> <[email protected]>:<destdir>/

Funktioniert auch beim Fortsetzen eines SCP, der unterbrochen wurde. 

Rsync erstellt eine temporäre Datei ... Die temporäre Datei wird schnell zu einer teilweise übertragenen Datei. Übertragung fortsetzen. 

Scp schreibt in die eigentliche Endzieldatei. Wenn die Übertragung unterbrochen wird, handelt es sich um eine abgeschnittene Datei.

Erklärung der Argumente:

-avhz .. h = humanoid, v = verbose, a = Archiv, z = Komprimierung .. archive weist es an, die time_t-Werte beizubehalten, sodass rsync auch bei ausgeschalteten Uhren das wahre Datum jeder Datei kennt

-P steht für - partial - progress. --partial weist rsync an, teilweise übertragene Dateien beizubehalten (und bei Wiederaufnahme verwendet rsync teilweise übertragene Dateien immer nach der Prüfsumme sicher)

Von den Manpages: 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.

HINWEIS: für eine Verbindung, die mehrmals unterbrochen wird: Wenn Sie nach rsync (nachdem die Verbindung unterbrochen wurde) fortsetzen müssen, sollten Sie die temporäre Datei am Zielort umbenennen. scp erstellt am Ziel eine Datei mit demselben Namen wie die endgültige Datei. Wenn scp unterbrochen wird, handelt es sich bei dieser Datei um eine abgeschnittene Version der Datei. Ein rsync (-avzhP) wird von dieser Datei wieder aufgenommen, beginnt jedoch in einen temporären Dateinamen wie ..Yhg7al zu schreiben. 

Vorgehensweise beim Start mit scp:

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

Vorgehensweise beim Start mit rsync: 

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

Ich habe festgestellt, dass das Hinzufügen von --inplace es behebt. Ich weiß nicht, wie --partial ohne es funktionieren soll, aber es hat meine Überweisungen wieder aufgenommen. Meine Dateien sind immer noch ziemlich groß, und ich frage mich, ob ich mit beschädigten Dateien enden werde, wenn eine Übertragung beginnt und Stunden später eine andere Übertragung beginnt, aber eine unvollständige Datei sieht und nicht weiß, dass sie gerade hochgeladen wird und dann Bytes hinzufügt es. Weiß jemand? Vielleicht ein bisschen Bash-Scripting, um die aktuelle Prozess-ID zu protokollieren und keine weitere Übertragung zu starten?

2
Glitches

wenn Sie nach einem Lebenslauf Angst vor beschädigten Dateien haben, können Sie --checksum hinzufügen, um zu erzwingen, dass die gesamte Datei jedes Mal überprüft wird. In der Tat kostet dies einige Festplatten-E/A- und CPU-Zyklen, jedoch nur einen geringen Netzwerkaufwand.

0
mogul