rsync über VPN: ein neuer Versuch, der den abgebrochenen Transfer wiederverwendet

Ihr Upload bleibt bei vier Gigabyte eines zwölf Gigabyte großen Archivs stehen, und die von Download-Managern gelernte Gewohnheit sagt, Fortsetzen zu drücken. rsync setzt den TCP-Strom nicht fort, denn dieser Strom ist mit der letzten Neuübertragung des Tunnels verschwunden. Was es tun kann, ist die bereits empfangenen Bytes zu behalten und sie als Grundlage für den nächsten Versuch zu nutzen — ein anderer Mechanismus mit einem anderen Regelwerk. Die Flags, die Sie wählen, entscheiden, ob diese Wiederverwendung überhaupt stattfindet.

Der neue Versuch baut Zustand neu auf, er setzt den Strom nicht fort

Wenn die SSH-Sitzung abbricht, bleibt am entfernten Ende nur, was es auf die Platte geschrieben hat, und sonst nichts. Es gibt kein Sitzungstoken, an das man wieder anknüpfen könnte, und keine Sequenznummer, die sich abspielen ließe. Der nächste Lauf öffnet eine neue Verbindung, liest die Quelle erneut und fragt den Empfänger, was er bereits hat.

Diese letzte Frage ist der Grund, warum eine Teil-Datei es wert ist, behalten zu werden. Die Kopie des Empfängers gibt rsync etwas zum Vergleichen, und der Algorithmus sendet nur die Unterschiede, die er erkennen kann. Es bleibt ein neuer Transfer von Metadaten und ein neuer Durchlauf über die Quelle, die gesparte Zeit ist also proportional dazu, wie viel der Datei übereinstimmt, nicht dazu, wie weit die vorherige Verbindung gekommen war. Hat der Empfänger nichts behalten, ist der nächste Versuch eine vollständige Kopie, egal wie viele Gigabyte der erste bewegt hat.

Entscheiden Sie, wo das wiederverwendbare Fragment liegt

Das Standardverhalten schreibt die Teil-Datei auf den Zielpfad, wodurch ein halb geschriebenes Archiv unter dem endgültigen Namen sichtbar wird. --partial-dir verschiebt sie in ein Verzeichnis Ihrer Wahl, und das Handbuch beschreibt dieses Verzeichnis als aufbewahrt, um von einem späteren Transfer als Daten genutzt zu werden. Ein relativer Name wird unter dem Zielverzeichnis aufgelöst, was genau das ist, was Sie wollen, wenn beide Seiten unterschiedliche Layouts haben können.

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

Auch am Ziel zählt die Reihenfolge: Das Teil-Verzeichnis braucht genug Platz für das Fragment, und das Volume braucht auch genug für die fertige Datei. Das Ziellaufwerk mitten im Transfer zu füllen erzeugt einen Fehler, der wie ein Netzwerkproblem aussieht, aber keines ist, und kann das aufbewahrte Fragment abgeschnitten zurücklassen. Prüfen Sie freien Platz auf dem empfangenden Host, bevor der Lauf beginnt, nicht danach. Ein paar Sekunden mit df -h über denselben SSH-Weg sind der billigstmögliche Test des Plans.

Berechtigungen sind ein kleineres, aber reales Anliegen. Ein Teil-Verzeichnis, in das fremde Konten schreiben können, erlaubt es anderen, Inhalte zu ersetzen, die Ihr nächster Lauf als bereits empfangen behandelt. Halten Sie es im Besitz des Transfer-Kontos und legen Sie es nicht dorthin, wo andere Dienste veröffentlichen.

Führen Sie dieselbe Kopie aus, keine klügere

Die Wiederverwendung gilt nur, wenn Quelle und Ziel noch dasselbe Objekt beschreiben. Gleicher Pfad, gleicher Name, gleiche Datei. Das Umbenennen der Quelle oder das Zeigen auf ein anderes Zielverzeichnis beginnt einen neuen Vergleich gegen nichts Nützliches.

Fügen Sie --whole-file nicht hinzu, während Sie das Delta-Verhalten erwarten. Diese Option weist rsync an, die ganze Datei ohne den Vergleich gleitender Prüfsummen zu kopieren, was auf einer schnellen lokalen Verbindung vernünftig und nach einem gescheiterten Ferntransfer genau falsch ist. --inplace ändert die Geschichte ebenfalls: Es schreibt direkt in die Zieldatei, sodass eine Unterbrechung eine Datei hinterlässt, die alten und neuen Inhalt mischt, ohne ein separates Fragment zum Zurückfallen.

Die Fortschrittszeile meldet den Gesamtfortschritt des Transfers. Sie ist kein Fertigstellungssignal. Eine Zahl, die hundert Prozent erreicht, während die Verbindung noch offen ist, bedeutet, dass die Daten geschoben wurden, nicht dass der Empfänger etwas umbenannt, synchronisiert oder angenommen hat.

Nehmen Sie das Objekt erst an, wenn es übereinstimmt

Bestätigen Sie zuerst den Exit-Status und vergleichen Sie dann das Ergebnis, statt auf die Abwesenheit von Fehlern zu vertrauen. Eine Größenprüfung fängt die meisten abgeschnittenen Transfers; ein Prüfsummenvergleich fängt den Rest, und beides ist billig im Vergleich zum erneuten Upload.

Wird das Archiv von einem nachgelagerten Prozess veröffentlicht, lassen Sie diesen Prozess auf die angenommene Datei warten. Ein aufbewahrtes Fragment, das unter dem endgültigen Namen in einem überwachten Verzeichnis landet, wird vom nächsten Scan aufgenommen, und der Fehler des Verbrauchers betrifft dann beschädigte Eingaben statt eines Transfers, der nie fertig wurde.

Lassen Sie die Quelle in Ruhe, bis der Empfänger bestätigt. Das Archiv zwischen Versuchen neu zu erzeugen ändert die Vergleichsbasis, und der nächste Lauf überträgt entweder fast alles oder erzeugt eine Datei, die weder zur alten noch zur neuen Quelle passt.

Wenn die Verbindung, nicht das Flag, die Grenze ist

Header- und Protokoll-Overhead sind eine Kosten eines Transfers, und selten die, die entscheidet, wie lange eine große Datei dauert. Das Neustartverhalten zählt mehr: Eine Methode, die einen Abbruch ohne manuelle Schritte übersteht, liefert eher eine brauchbare Datei als eine schnellere Methode, die neu beginnen muss. Speicher an beiden Enden und der Authentifizierungspfad gehören in denselben Vergleich.

Vergleichen Sie erlaubte alternative Wege mit derselben Datei und demselben Ziel, und notieren Sie, wo jeder nach einer Unterbrechung wieder ansetzt. Diese eine Spalte sagt Ihnen mehr über einen Upload von zwölf Gigabyte über ein VPN als jede Spitzenrate, die in einem kurzen Test gemessen wurde.