
Zu Sicherungszwecken habe ich eine sehr große Binärdatei über eine vergleichsweise langsame Upstream-Verbindung übertragen (die Übertragung dauerte 2 Wochen), indem ich sie per Rsync auf eine gemountete CIFS-Freigabe synchronisiert habe (so konnte und kann ich blockweise darauf zugreifen). Nach den 2 Wochen zeigte Rsync einen Fehler an (konnte sie leider nicht speichern), aber die Dateigröße stimmte überein.
tail -c 1000000000 myfile.img|md5sum # and
head -c 1000000000 myfile.img|md5sum
übereinstimmen, sodass Anfang und Ende der Datei identisch sind.
Da mein Downstream viel schneller ist, habe ich das vollständige Image erneut heruntergeladen und MD5-Summen über das Ganze erstellt, und diese stimmen NICHT überein. Also ist anscheinend irgendwo in diesen 1,5 TB mindestens ein Bit anders.
Gibt es eine Möglichkeit, aus den beiden heruntergeladenen Dateien einen „Patch“ zu generieren und diesen dann auf die Remote-Datei anzuwenden, sodass nur die falschen Blöcke erneut übertragen werden müssen?
Bitte noch einmal beachten: Ich habe NICHT die Möglichkeit, Code remote auszuführen oder die Funktionen von rsync zu nutzen, die eine Remote-Ausführung von rsync erfordern. Ich schätze, ich könnte immer noch rsync verwenden und es funktioniert in der Größenordnung meiner Downloadrate, aber ich frage mich, ob es eine bessere Möglichkeit gibt, die Tatsache auszunutzen, dass ich beide Versionen lokal habe. Es wäre wahrscheinlich nicht so schwer, etwas zu schreiben, aber ich würde lieber etwas Erprobtes verwenden und mir die Arbeit sparen.
Antwort1
(unter Linux) Wenn Sie glauben, dass nur ein oder mehrere Datenblöcke beschädigt sind, die Größe des Blocks sich aber nicht geändert hat, können Sie verwenden cmp -l
. Es vergleicht Byte für Byte und -l
gibt den Offset aller Unterschiede an. Wenn Sie eine vage Vorstellung davon haben, wo Sie in den Dateien beginnen sollen, können Sie mit einen ersten Start angeben -i
. Wenn Sie die Offsets fehlerhaft haben, können Sie dd skip=...
diese aus der Originaldatei ausschneiden und dd seek=... conv=notrunc
in die beschädigte Datei einfügen. (Zuerst auf Kopie testen)
Antwort2
Ich würde BitTorrent verwenden, um die Datei auf der Remote-Seite wiederherzustellen. Das Protokoll teilt eine Datei in kleine Blöcke auf und lädt Blöcke, deren Hashes nicht mit der Seed-Datei übereinstimmen, automatisch erneut herunter.
So funktioniert es in einer privaten Umgebung:
- Deaktivieren Sie DHT auf den lokalen und Remote-BitTorrent-Clients.
- Öffnen Sie lokale BitTorrent-Ports in der Firewall oder richten Sie eine SSH-Portweiterleitung ein.
- Erstellen Sie eine Seed-Datei auf der Quellseite. Verwenden Sie keinen Tracker. Stellen Sie sicher, dass der Client auch mit dem Seeding der Datei beginnt.
- Sichern Sie die Datei auf der Remote-Seite.
- Kopieren Sie die Seed-Datei auf die Remote-Seite und öffnen Sie sie mit dem Client.
- Zeigen Sie mit dem Download-Speicherort auf die beschädigte Datei und wählen Sie die Option zumden Download nicht starten!! Deaktivieren Sie auch die Optionen zur Verbindung mit DHT, Peer-Exchange usw., falls verfügbar.
- Bitten Sie den Client, die heruntergeladene Datei noch einmal zu prüfen. Er sollte einen fast abgeschlossenen Download-Prozentsatz melden.
- Fügen Sie den lokalen Client als Peer zum Download hinzu
- Starten Sie den Download