Lösung 1:
rsync --ignore-existing --sparse ...
So erstellen Sie neue Dateien im Sparse-Modus
Gefolgt von
rsync --inplace ...
Zum Aktualisieren aller vorhandenen Dateien (einschließlich der zuvor erstellten Sparse-Dateien) inplace.
Lösung 2:
Rsync überträgt nur Änderungen in jede Datei und sollte mit --inplace nur die geänderten Blöcke neu schreiben, ohne die Datei neu zu erstellen. Von ihrer Funktionsseite.
rsync ist ein Dateiübertragungsprogramm für Unix-Systeme. rsync verwendet den "rsync-Algorithmus", der eine sehr schnelle Methode bietet, um entfernte Dateien zu synchronisieren. Dies geschieht, indem nur die Unterschiede in den Dateien über den Link gesendet werden, ohne dass vorher beide Dateisätze an einem der Enden des Links vorhanden sein müssen.
Die Verwendung von --inplace sollte für Sie funktionieren. Dies zeigt Ihnen den Fortschritt, komprimiert die Übertragung (auf der Standardkomprimierungsstufe), überträgt den Inhalt des lokalen Speicherverzeichnisses rekursiv (der erste abschließende Schrägstrich ist wichtig), nimmt die Änderungen an den vorhandenen Dateien vor und verwendet ssh für den Transport.
rsync -v -z -r --inplace --progress -e ssh /path/to/local/storage/ \
[email protected]:/path/to/remote/storage/
Ich verwende oft auch das Flag -a, das noch ein paar Dinge tut. Es ist äquivalent zu -rlptgoD. Das genaue Verhalten überlasse ich Ihnen zum Nachschlagen in der Manpage.
Lösung 3:
Werfen Sie einen Blick auf das Zumastor Linux Storage Project, das eine „Snapshot“-Sicherung mit binärem „rsync“ über den ddsnap
implementiert Werkzeug.
Von der Manpage:
ddsnap bietet Blockgerätereplikation mit einer Snapshot-Funktion auf Blockebene, die in der Lage ist, mehrere gleichzeitige Snapshots effizient zu speichern. ddsnap kann eine Liste von Snapshot-Chunks generieren, die sich zwischen zwei Snapshots unterscheiden, und diese Differenz dann über die Leitung senden. Schreiben Sie auf einem Downstream-Server die aktualisierten Daten auf ein Snapshot-Blockgerät.
Lösung 4:
Am Ende habe ich Software geschrieben, um dies zu tun:
http://www.virtsync.com
Dies ist eine kommerzielle Software, die 49 $ pro physischem Server kostet.
Ich kann jetzt eine 50-GB-Sparse-Datei (mit 3 GB Inhalt) in weniger als 3 Minuten über das private Breitband replizieren.
[email protected]:~$ time virtsync -v /var/lib/libvirt/images/vsws.img backup.barricane.com:/home/chris/
syncing /var/lib/libvirt/images/vsws.img to backup.barricane.com:/home/chris/vsws.img (dot = 1 GiB)
[........>.........................................]
done - 53687091200 bytes compared, 4096 bytes transferred.
real 2m47.201s
user 0m48.821s
sys 0m43.915s
Lösung 5:
Um große Dateien oder Blockgeräte mit geringen bis mittleren Unterschieden zu synchronisieren, können Sie entweder eine einfache Kopie erstellen oder bdsync verwenden, rsync ist für diesen speziellen Fall absolut nicht geeignet *.
bdsync
hat für mich funktioniert, scheint ausgereift genug zu sein, die Fehlergeschichte ist ermutigend (kleine Probleme, schnelle Lösung). In meinen Tests war die Geschwindigkeit nahe am theoretischen Maximum, das Sie erreichen konnten ** (das heißt, Sie können ungefähr die Zeit synchronisieren, die Sie zum Lesen der Datei benötigen). Endlich ist es Open Source und kostet nichts.
bdsync
liest die Dateien von beiden Hosts und tauscht Prüfsummen aus, um sie zu vergleichen und Unterschiede zu erkennen. All dies gleichzeitig . Schließlich erstellt es eine komprimierte Patch-Datei auf dem Quellhost. Dann verschieben Sie diese Datei auf den Zielhost und führen bdsync ein zweites Mal aus, um die Zieldatei zu patchen.
Bei Verwendung über eine ziemlich schnelle Verbindung (z. B. 100-Mbit-Ethernet) und für Dateien mit kleinen Unterschieden (wie dies bei VM-Festplatten meistens der Fall ist) verkürzt es die Zeit zum Synchronisieren auf die Zeit, die Sie zum Lesen der Datei benötigen. Über eine langsame Verbindung benötigen Sie etwas mehr Zeit, da Sie die komprimierten Änderungen von einem Host auf den anderen kopieren müssen (es scheint, dass Sie mit einem netten Trick Zeit sparen können, aber nicht getestet haben). Bei Dateien mit vielen Änderungen sollte auch die Zeit zum Schreiben der Patch-Datei auf die Festplatte berücksichtigt werden (und Sie benötigen genügend freien Speicherplatz auf beiden Hosts, um sie zu speichern).
So verwende ich normalerweise bdsync. Diese Befehle werden auf $LOCAL_HOST
ausgeführt um $LOCAL_FILE
zu "kopieren". bis $REMOTE_FILE
auf $REMOTE_HOST
. Ich verwende pigz
(ein schnelleres gzip
), um die Änderungen zu komprimieren, ssh
um bdsync auf dem entfernten Host auszuführen und rsync
/ssh
um die Änderungen zu kopieren. Beachten Sie, dass ich überprüfe, ob der Patch erfolgreich angewendet wurde, aber ich nur „Update erfolgreich“ drucke, wenn dies der Fall ist. Vielleicht möchten Sie im Falle eines Scheiterns etwas mehr Clevel machen.
REMOTE_HOST=1.2.3.4
LOCAL_FILE=/path/to/source/file
REMOTE_FILE=/path/to/destination/file
PATCH=a_file_name
LOC_TMPDIR=/tmp/
REM_TMPDIR=/tmp/
# if you do use /tmp/ make sure it fits large patch files
# find changes and create a compressed patch file
bdsync "ssh $REMOTE_HOST bdsync --server" "$LOCAL_FILE" "$REMOTE_FILE" --diffsize=resize | pigz > "$LOC_TMPDIR/$PATCH"
# move patch file to remote host
rsync "$LOC_TMPDIR/$PATCH" $REMOTE_HOST:$REM_TMPDIR/$PATCH
# apply patch to remote file
(
ssh -T $REMOTE_HOST <<ENDSSH
pigz -d < $REM_TMPDIR/$PATCH | bdsync --patch="$REMOTE_FILE" --diffsize=resize && echo "ALL-DONE"
rm $REM_TMPDIR/$PATCH
ENDSSH
) | grep -q "ALL-DONE" && echo "Update succesful" && rm "$LOC_TMPDIR/$PATCH"
# (optional) update remote file timestamp to match local file
MTIME=`stat "$LOCAL_$FILE" -c %Y`
ssh $REMOTE_HOST touch -c -d @"$MTIME_0" "$REMOTE_FILE" </dev/null
*:rsync ist bei großen Dateien äußerst ineffizient. Selbst mit --inplace wird zuerst die gesamte Datei auf dem Zielhost gelesen, DANACH mit dem Lesen der Datei auf dem Quellhost begonnen und schließlich die Unterschiede übertragen (einfach dstat oder ähnliches ausführen, während rsync ausgeführt wird, und beobachten). Das Ergebnis ist, dass es selbst bei Dateien mit kleinen Unterschieden etwa doppelt so lange dauert, bis Sie die Datei gelesen haben, um sie zu synchronisieren.
**:Unter der Annahme, dass Sie keine andere Möglichkeit haben, festzustellen, welche Teile der Dateien geändert wurden. LVM-Snapshots verwenden Bitmaps, um die geänderten Blöcke aufzuzeichnen, sodass sie extrem schneller sein können (Weitere Informationen finden Sie in der Readme-Datei von lvmsync).