Dies ist eine Erweiterung zuWarum versucht rsync, eine Datei zu kopieren, die bereits auf dem neuesten Stand ist?
Ich versuche, mit dem --copy-devicesPatch rsyncein ganzes Festplattenlaufwerk zu kopieren und es als Image auf einem anderen Computer zu speichern.
Das Kopieren scheint korrekt ausgeführt worden zu sein. Wenn ich es jedoch rsyncerneut mit denselben Werten ausführe, werden anscheinend jedes Mal einige Daten erneut kopiert.
Ich habe es rsyncmit erhöhter Ausführlichkeit ausprobiert und das hier bekommen:
$ sudo rsync -vvz --partial --progress --copy-devices /dev/sdb me@otherserver:/backupdisks/mydisk.img
opening connection using: ssh -l me otherserver rsync --server -vvze.Lsfx --partial --copy-devices . /backupdisks/mydisk.img (11 args)
me@otherserver's password:
delta-transmission enabled
sdb
320,071,851,520 100% 63.47MB/s 1:20:09 (xfr#1, to-chk=0/1)
total: matches=2441955 hash_hits=2441955 false_alarms=204015955 data=0
sent 188 bytes received 21,979,001 bytes 2,837.31 bytes/sec
total size is 0 speedup is 0.00
Mir ist bewusst, dass rsync Änderungen anhand der Zeit ermittelt, aber die Festplatte hat sich zwischen den rsync-Aufrufen nicht geändert (und wie soll es überhaupt die Änderungszeit einer Festplatte ermitteln?) Die Zeit auf dem Remote-Image wird jedoch jedes Mal aktualisiert. Das könnte also das Problem sein.
Die andere Möglichkeit besteht darin, dass die Festplatte einen fehlerhaften Sektor aufweist, der jedes Mal einen anderen Wert zurückgibt und die verwendete Prüfsumme negiert.
Meine Frage ist zweifach:
Wurde mein Image erfolgreich übertragen und wenn ja, warum wird bei einer erneuten Ausführung scheinbar ein großer Teil der Festplatte erneut übertragen? (Dies kann teilweise auch als Teil meiner Folgefrage beantwortet werdenWas sind „Übereinstimmungen“, „Hash_Hits“ und „Falschalarme“ in der Rsync-Ausgabe und bedeutet „data=0“ Erfolg?)
Übersehe ich einen Schalter, damit dies richtig funktioniert? (Vielleicht
--checksum?) Ist es möglich, die vom rsync-Algorithmus verwendeten Fehler auf Blockebene aufzulisten?
Antwort1
Standardmäßig vergleicht rsync Dateien nach Größe und Zeitstempel, aber ein Gerät hat keine Größe, daher muss es Unterschiede mit dem Delta-Algorithmus berechnen, der in diesem beschrieben wirdtechnischer Bericht. Die Remote-Datei wird grob in Blöcke einer gewählten Größe aufgeteilt und die Prüfsummen dieser Blöcke werden zurückgesendet. Die Prüfsummen der lokalen Datei werden auf ähnliche Weise in Blöcken ermittelt und mit der Liste verglichen. Dem Remote-Server wird dann mitgeteilt, wie er die Blöcke, die er zum Neuaufbau der Datei benötigt, wieder zusammensetzen muss, und die Daten für die Blöcke, die nicht übereinstimmen, werden gesendet.
Sie können dies sehen, indem Sie auf Ebene 3 nur für den Deltasum-Algorithmus mit der Option eine Debug-Ausgabe anfordern --debug=deltasum3. Sie können eine Blockgröße mit angeben, um -Bdie Zahlen zu vereinfachen. Beispielsweise wird für eine Datei, die bereits einmal kopiert wurde, ein zweiter Durchlauf von
rsync -B 100000 --copy-devices -avv --debug=deltasum3 --no-W /dev/sdd /tmp/mysdd
erzeugt eine Ausgabe wie diese, die die Prüfsumme für jeden Block anzeigt:
count=164 rem=84000 blength=100000 s2length=2 flength=16384000
chunk[0] offset=0 len=100000 sum1=61f6893e
chunk[1] offset=100000 len=100000 sum1=32f30ba3
chunk[2] offset=200000 len=100000 sum1=45b1f9e5
...
Sie können dann ziemlich einfach erkennen, dass die Prüfsumme mit der des anderen Geräts übereinstimmt, da es keine Unterschiede gibt:
potential match at 0 i=0 sum=61f6893e
match at 0 last_match=0 j=0 len=100000 n=0
potential match at 100000 i=1 sum=32f30ba3
match at 100000 last_match=100000 j=1 len=100000 n=0
potential match at 200000 i=2 sum=45b1f9e5
match at 200000 last_match=200000 j=2 len=100000 n=0
...
Am Ende data=ist das Feld 0 und zeigt an, dass keine neuen Daten gesendet wurden.
total: matches=164 hash_hits=164 false_alarms=0 data=0
Wenn wir jetzt die Kopie beschädigen, indem wir die Mitte der Datei überschreiben:
echo test | dd conv=block,notrunc seek=80 bs=100000 of=/tmp/mysdd
touch -r /dev/sdd /tmp/mysdd
dann zeigt uns der Rsync-Debug eine neue Prüfsumme für Block 80, aber keine Übereinstimmung dafür. Wir gehen von Übereinstimmung 79 zu Übereinstimmung 81:
chunk[80] offset=8000000 len=100000 sum1=a73cccfe
...
potential match at 7900000 i=79 sum=58eabec6
match at 7900000 last_match=7900000 j=79 len=100000 n=0
potential match at 8100000 i=81 sum=eba488ba
match at 8100000 last_match=8000000 j=81 len=100000 n=100000
Am Ende wird data=100000angezeigt, dass ein ganz neuer Datenblock gesendet werden musste.
total: matches=163 hash_hits=385 false_alarms=0 data=100000
Die Anzahl der Übereinstimmungen wurde um 1 reduziert, da die Prüfsumme des beschädigten Blocks nicht übereinstimmte. Vielleicht steigen die Hash-Treffer, weil wir die sequentielle Übereinstimmung verloren haben.
Wenn wir schauenweiterIm selben technischen Bericht werden einige Testergebnisse gezeigt und diefalscher Alarm werden beschrieben als „die Anzahl der Male, die die 32-Bit-Rollprüfsumme übereinstimmte, die starke Prüfsumme jedoch nicht“. Jeder Block hat eine einfache Prüfsumme und eine MD5-Prüfsumme (MD4 in älteren Versionen). Die einfache Prüfsumme lässt sich mithilfe einer Hash-Tabelle leicht suchen, da es sich um eine 32-Bit-Ganzzahl handelt. Sobald sie mit einem Eintrag übereinstimmt, wird auch die längere 16-Byte-MD5-Prüfsumme verglichen. Wenn sie nicht übereinstimmt, handelt es sich um einen Fehlalarm und die Suche wird fortgesetzt.
In meinem Beispiel wird ein sehr kleines (und altes) USB-Stick-Gerät mit 16 MB verwendet, und die Mindestgröße der Hash-Tabelle beträgt 2**16, also 65536 Einträge. Daher ist sie ziemlich leer, wenn ich die 164 Chunk-Einträge speichere, die ich habe. So viele Fehlalarme sind normal und eher ein Hinweis auf die Effizienz als auf irgendetwas anderes.
Antwort2
Sie sollten die Verwendung von rsync --partial --inplacesowie Ihre anderen Optionen in Betracht ziehen, da sonst während der Arbeit eine vollständige Kopie des Disk-Images auf der Zielseite erstellt wird. Ich habe -B 4096auch verwendet, da dies die natürliche Sektorgröße des Geräts ist und die Standardblockgröße von rsync für diese Art von Vorgang zu klein ist.
Um zu überprüfen, ob das Image vollständig und richtig kopiert wurde, würde ich eine unabhängige Kopie sha1sumsowohl auf der Quell- als auch auf der Zielseite empfehlen. Das sollte nicht notwendig sein, aber wenn Sie sicher sein wollen, ist das ganz einfach und Sie können darauf vertrauen. Ich gehe davon aus, dass Ihre Quelldiskette kein Live-Mount oder etwas dergleichen ist, sonst ist alles möglich und es gibt keine zuverlässige Methode, es zu senden.