Synchronisieren Sie zwei weitgehend identische große Dateien

Ich habe zwei 300-GB-Dateien auf verschiedenen Volumes:

verschlüsselte lokale Sicherung
verschlüsselte 'Remote'-Sicherung auf dem NAS).

Diese beiden Dateien sind vom Design her identisch und größtenteils (> 90%) inhaltlich identisch ...

Gibt es ein effizientes Tool, um diese Dateien zu „synchronisieren“ und nur über die verschiedenen Abschnitte zu kopieren, damit die Zieldatei mit der Quelle identisch wird?

Vielleicht etwas, das Prüfsummen von Blöcken erstellt, um das herauszufinden, weiß ich nicht ... (etwas effizienter als cp -f... rsync würde afaik auch die gesamte Quelldatei zum Überschreiben greifen)

— Frank Nocke
quelle

Warum sollten Sie das Risiko eingehen, Dateibereiche zu synchronisieren, wenn Sie sie dadurch möglicherweise beschädigen können? Gute Frage.

— ankit7540

Warum sind die Backups nur zu 90% + identisch? Ich würde annehmen, dass sie bereits gleich sein sollten, wenn das Ihr Ziel ist. Wie entstehen sie? Siehe auch

— Elder Geek

1) Ich werde über Korruption Bescheid wissen, indem ich einen Hash verwende. 2) Die verschlüsselten Bilder enthalten nur wenige Änderungen, sie werden nie vollständig oder zu einem größeren Teil neu geschrieben ... also ist es wie Sektoren auf einer Festplatte (nur wenige Änderungen Woche für Woche)

— Frank Nocke

Ist es nicht möglich, von einem anderen Ende aus zu beginnen, als Backups nicht als Monolith-Images zu generieren? Vielleicht könnten Sie beispielsweise Dateisystem-Images verwenden, diese bereitstellen, dort sichern, die Bereitstellung aufheben und verschlüsseln.

— wk.

Wenn ich mich nicht irre, kann rsync einen Delta-Transfer-Algorithmus verwenden, um nur die verschiedenen Teile zu übertragen. Versuchen Sie es mit der Option --no-W zu erzwingen. Versuchen Sie --no-ganze-Datei, wenn das nicht funktioniert.

— Barotto

Antworten:

rsync kann verwendet werden, um dies zu tun.

--no-whole-fileoder --no-WParameter verwenden die Synchronisierung auf Blockebene anstelle der Synchronisierung auf Dateiebene.

Testfall

Generierte zufällige Textdateien unter Verwendung /dev/randomund großer Teile von Textdateien von Websites wie folgt. Diese 4 Dateien unterscheiden sich in allen Inhalten. tf_2.datist unsere Zieldatei.

~/logs/rs$ ls -tlh    
-rw-rw-r-- 1 vayu vayu 2.1G  二  25 23:11 tf_2.dat
-rw-rw-r-- 1 vayu vayu 978M  二  25 23:11 a.txt
-rw-rw-r-- 1 vayu vayu 556K  二  25 23:10 file2.txt
-rw-rw-r-- 1 vayu vayu 561K  二  25 23:09 nt.txt

Kopieren Sie sie dann mit auf eine andere Festplatte rsync(das Ziel ist leer).

rsync -r --stats rs/ /mnt/raid0/scratch/t2

Die folgende Statistik wurde empfangen.

Number of files: 5 (reg: 4, dir: 1)
Number of created files: 0
Number of deleted files: 0
Number of regular files transferred: 4
Total file size: 3,260,939,140 bytes
Total transferred file size: 3,260,939,140 bytes
Literal data: 3,260,939,140 bytes
Matched data: 0 bytes
File list size: 0
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 3,261,735,553
Total bytes received: 92

sent 3,261,735,553 bytes  received 92 bytes  501,805,483.85 bytes/sec
total size is 3,260,939,140  speedup is 1.00

Jetzt füge ich die Dateien zusammen, um eine neue Datei zu erstellen, die ca. 60% alte Daten enthält.

cat file2.txt a.txt >> tf_2.dat

Jetzt synchronisiere ich die beiden Ordner, diesmal mit der --no-WOption.

rsync -r --no-W --stats rs/ /mnt/raid0/scratch/t2

Number of files: 5 (reg: 4, dir: 1)
Number of created files: 0
Number of deleted files: 0
Number of regular files transferred: 4
Total file size: 4,289,593,685 bytes
Total transferred file size: 4,289,593,685 bytes
Literal data: 1,025,553,047 bytes
Matched data: 3,264,040,638 bytes
File list size: 0
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 1,026,127,265
Total bytes received: 611,604

sent 1,026,127,265 bytes  received 611,604 bytes  21,169,873.59 bytes/sec
total size is 4,289,593,685  speedup is 4.18

Sie können sehen, dass große Datenmengen übereinstimmen und beschleunigt werden.

Als nächstes versuche ich es erneut. Dieses Mal füge ich mehrere Shell-Dateien mit dem Ziel ( tf_2.dat) zusammen, sodass die Änderung ~ 2% beträgt.

cat *.sh >> rs/tf_2.dat

Und wieder mit synchronisieren rsync.

rsync -r --no-whole-file --stats rs/ /mnt/raid0/scratch/t2


Number of files: 5 (reg: 4, dir: 1)
Number of created files: 0
Number of deleted files: 0
Number of regular files transferred: 4
Total file size: 4,289,727,173 bytes
Total transferred file size: 4,289,727,173 bytes
Literal data: 178,839 bytes
Matched data: 4,289,548,334 bytes
File list size: 0
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 541,845
Total bytes received: 690,392

sent 541,845 bytes  received 690,392 bytes  43,236.39 bytes/sec
total size is 4,289,727,173  speedup is 3,481.25

Wir sehen eine große Übereinstimmung und Beschleunigung, die eine schnelle Synchronisierung ermöglichen.

— ankit7540
quelle

Deshalb staple ich über. Einfachste Lösung. Akzeptiert!

— Frank Nocke

Ich frage mich, ob die Ergebnisse gleich sind, wenn sich ein Block irgendwo in der Mitte ändert ... (unveränderte Blöcke dahinter müssen natürlich die Position beibehalten (auch bekannt als offest), andernfalls wird es zu einem kostspieligen Umschreiben. Ich weiß, dass ich als C-Programmierer ... .)

— Frank Nocke

Und ich frage mich, ob dies -no-whole-fileimpliziert --inplace( diese Leute wundern sich über die entgegengesetzte Richtung). - So oder so kann es wahrscheinlich nicht schaden, diesen Parameter auch hinzuzufügen.

— Frank Nocke

Ich habe es versucht --inplace, aber das hat nicht funktioniert.

— ankit7540

Ich denke nicht , die --inplacenur führt , dass die Daten zuerst in eine parallelen Datei kopiert werden (a .hidden ein, wie ich langsam das Gigabyte beobachten konnte Aufbau) und erst dann die alten zu löschen und die tmp - Datei auf den Namen umbenennen ... wie auch immer, Mit -no-ganze-Datei sollte dies sowieso ein Muss sein.

— Frank Nocke

Sie können auch versuchen, https://bitbucket.org/ppershing/blocksync zu verwenden (Haftungsausschluss: Ich bin der Autor dieser speziellen Gabel). Ein Vorteil gegenüber rsync besteht darin, dass die Datei nur einmal gelesen wird (soweit ich weiß, kann rsync nicht davon überzeugt werden, dass zwei Dateien unterschiedlich sind, ohne die Prüfsumme zu berechnen, bevor die Delta-Übertragung gestartet wird. Es ist unnötig zu erwähnen, dass 160 GB Festplatten zweimal gelesen werden ist keine gute Strategie). Ein Hinweis zur Vorsicht: Die aktuelle Version von Blocksync funktioniert gut über kurze RTT-Verbindungen (z. B. Localhost, LAN und lokales WLAN), ist jedoch für die Synchronisierung über große Entfernungen nicht besonders nützlich.

— user3584196
quelle