☰

Große Rsync-Übertragungen in Blöcke aufteilen?

tag-icon • tag-icon backup rsync file-transfer
Große Rsync-Übertragungen in Blöcke aufteilen?

Wir verwenden rsync, um ein Spiegelbild unseres primären Dateiservers auf einen externen Backup-Server zu aktualisieren. Eines unserer aktuellen Probleme ist, dass unser Dateiserver über 1 TB an überwiegend kleineren Dateien (im Bereich von 10 bis 100 KB) verfügt. Wenn wir so viele Daten übertragen, wird die Verbindung häufig nach mehreren Stunden unterbrochen. Rsync verfügt nicht über eine Funktion zum Fortsetzen/Wiederholen, die einfach die Verbindung zum Server wiederherstellt, um dort fortzufahren, wo sie aufgehört hat. Sie müssen den Dateivergleichsprozess durchlaufen, der bei der Menge der Dateien, die wir haben, sehr langwierig ist.

Die empfohlene Lösung besteht darin, Ihren großen rsync-Transfer in eine Reihe kleinerer Transfers aufzuteilen. Ich bin zu dem Schluss gekommen, dass dies am besten über den Anfangsbuchstaben der Verzeichnisnamen der obersten Ebene funktioniert. Damit erhalten wir zwar keine perfekt gleichmäßige Verteilung, aber es ist gut genug.

Ich möchte bestätigen, dass meine Vorgehensweise vernünftig ist oder ob es einen einfacheren Weg gibt, das Ziel zu erreichen.

Dazu iteriere ich durch AZ, az, 0-9, um ein Zeichen auszuwählen $prefix. Ursprünglich wollte ich nur ausführen

rsync -av --delete --delete-excluded --exclude "*.mp3" "src/$prefix*" dest/

(--exclude "*.mp3" ist nur ein Beispiel, da wir eine längere Ausschlussliste zum Entfernen von Dingen wie temporären Dateien haben)

Das Problem dabei ist, dass alle Top-Level-Verzeichnisse in dest/, die nicht mehr in src vorhanden sind, von --delete nicht erkannt werden. Um das zu umgehen, versuche ich stattdessen Folgendes:

rsync \
--filter 'S /$prefix*' \
--filter 'R /$prefix*' \
--filter 'H /*' \
--filter 'P /*' \
-av --delete --delete-excluded --exclude "*.mp3" src/ dest/

Ich verwende „ showund“ hidestatt include„und“ exclude, weil sonst die Option --delete-excluded alles löscht, was nicht mit $prefix übereinstimmt.

Ist dies die effektivste Methode, um rsync in kleinere Teile aufzuteilen? Gibt es ein effektiveres Tool oder ein Flag, das ich übersehen habe und das dies einfacher machen könnte?

Antwort1

Meine Lösung hierfür war ein anderer Ansatz mit zwei Durchgängen, bei dem ich etwas Speicherplatz einspare. Ich führe rsync --only-write-batch auf dem Server aus und synchronisiere dann die Batchdatei selbst mit dem Ziel. Dabei führe ich eine Schleife aus, bis das rsync erfolgreich ist. Sobald die Batchdatei vollständig abgeschlossen ist, werden mit rsync --read-batch auf dem Ziel alle Änderungen wiederhergestellt.

Dies hat für mich auch einige unbeabsichtigte Vorteile:

  • weil ich mehr daran interessiert bin, dass das Backup "existiert" als dass es "verwendbar" ist, führe ich den Lese-Batch auf der Empfangsseite nicht jeden Tag aus -- meistens ist der Batch relativ klein

  • Ich habe mit --checksum-seed=1 experimentiert ... Vielleicht lese ich die Dokumentation falsch, aber ich glaube, dass die Batchdateien dadurch besser synchronisierbar sind (d. h. wenn ich an einem bestimmten Tag --read-batch nicht ausführe, wird der Batch des nächsten Tages schneller synchronisiert, weil der Batch des vorherigen Tages eine gute Grundlage darstellt).

  • Wenn der Stapel zu groß wird, um ihn „rechtzeitig“ über das Internet zu senden, kann ich ihn per Sneaker-Net auf ein externes Laufwerk übertragen. Mit „rechtzeitig“ meine ich, dass ich den Stapel nicht übertragen und lesen kann, bevor die Sicherung am nächsten Tag beginnt.

  • obwohl ich das persönlich nicht mache, könnte ich zwei externe Backups an verschiedenen Standorten haben und den Stapel an beide senden.

Antwort2

Das beantwortet Ihre Frage nicht direkt, aber eine andere Möglichkeit, die ich ziemlich oft verwende, ist ein zweistufiger Ansatz: Zuerst eine Dateiliste erstellen, dann die Liste der zu übertragenden Dateien aufteilen und die Dateiliste in rsync/cpio/cp usw. einspeisen.

rsync --itemize-changes <rest of options>druckt eine Liste der zu übertragenden Dateien mit einer Reihe nützlicher Metadaten aus. Aus dieser Ausgabe können relativ einfach die Dateinamen extrahiert und dann der eigentliche Kopiervorgang mit einem dieser rsync --files-fromTools oder einem anderen durchgeführt werden.

Könnte in Ihrer Situation nützlich sein – die Fortsetzung einer abgebrochenen Übertragung wäre viel schneller.

Antwort3

Ich würde Ihnen vorschlagen, das Verbindungsproblem im Auge zu behalten, anstatt zu versuchen, es durch die Schaffung eines anderen „Problems“ zu lösen.

Das ist kein übliches Verhalten. Verwenden Sie rsync über SSH oder rsyncd?

Soweit ich weiß, treten die meisten „geschlossenen“ Verbindungen auf, wenn keine Daten zwischen den Endpunkten übertragen werden.

verwandte Informationen