Macht dd irgendeine Art von Verifikation?

Ich benutze, ddum Daten von einer alten Festplatte auf eine neue zu kopieren. Ich möchte sicherstellen, dass die Integrität der Daten sicher ist.

Zu dieser Antwort sagt Gilles

Wenn [dd] erfolgreich beendet wurde, ist die Sicherung korrekt, es sei denn, es liegt ein Hardwarefehler vor.

Was heißt das genau? Hat ddeine Art von Verifikation eingebaut?

Wenn ich stattdessen rsync verwenden würde, würde ich auch einen zweiten Durchgang mit ausführen --checksum, um dies zu überprüfen. Ist diese Art von Paranoia gerechtfertigt?

ddoder eine andere Anwendung hat keine "eingebaute Verifikation" in dem Sinne, an den Sie wahrscheinlich denken: Sie liest nicht die Daten vom Speichermedium zurück, um sie mit dem zu vergleichen, was geschrieben wurde. Das ist die Aufgabe des Betriebssystems.

Es ist nicht wirklich möglich, aus einer Anwendung heraus eine Leseüberprüfung auf die Hardware durchzuführen. In einigen Szenarien würde dies funktionieren, in den meisten Fällen jedoch nichts bewirken. Die Anwendung könnte zurücklesen, was sie gerade geschrieben hat, wenn sie direkt auf ein Speichermedium schreibt , aber das würde normalerweise aus einem speicherinternen Cache zurücklesen, was keine nützliche Sicherheit geben würde. In dem Beispiel, das Sie zitieren , ddwird in eine Pipe geschrieben, und in diesem Fall hat es keine Kontrolle darüber, was mit den Daten weiter unten in der Zeile geschieht. In Ihrem RSYNC-Beispiel ein zweiter Durchgang vonrsync --checksum Das ist sinnlos: Theoretisch könnte es einen Fehler auffangen, aber in der Praxis würde der zweite Durchgang wahrscheinlich nichts Falsches melden, wenn ein Fehler auftritt. Sie verschwenden also Mühe mit etwas, das keine wirklich nützliche Sicherheit bietet.

Allerdings Anwendungen Sie überprüfen , was passiert mit den Daten, in dem Sinne , dass sie überprüfen, ob das Betriebssystem akzeptiert die Verantwortung für die Daten hat. Alle Systemaufrufe geben einen Fehlerstatus zurück. Wenn ein Systemaufruf einen Fehlerstatus zurückgibt, sollte die Anwendung diesen Fehler an den Benutzer weitergeben, indem im Allgemeinen eine Fehlermeldung angezeigt und ein Exit-Status ungleich Null zurückgegeben wird.

Beachten Sie, dass dies ddeine Ausnahme darstellt: Abhängig von den Befehlszeilenparametern ddkönnen einige Fehler ignoriert werden . Dies ist äußerst ungewöhnlich: Dies ist ddder einzige häufig verwendete Befehl mit dieser Eigenschaft. Verwenden Sie catstattdessen dd, so riskieren Sie keine Korruption und es kann auch schneller sein .

Bei einer Datenkopierkette können zwei Arten von Fehlern auftreten.

• Korruption: Während der Übertragung wird ein bisschen gewendet. Es gibt keine Möglichkeit, dies auf Anwendungsebene zu überprüfen, da dies auf einen Programmierfehler oder einen Hardwarefehler zurückzuführen ist, der beim Zurücklesen mit hoher Wahrscheinlichkeit dieselbe Beschädigung verursacht. Der einzige nützliche Weg, um sicherzustellen, dass keine solche Beschädigung aufgetreten ist, besteht darin, das Medium physisch zu trennen und es erneut zu versuchen, vorzugsweise auf einem anderen Computer, falls das Problem mit dem RAM bestand.
• Abschneiden: Alle kopierten Daten wurden korrekt kopiert, aber einige der Daten wurden überhaupt nicht kopiert. Dieser ist manchmal eine Prüfung wert, abhängig von der Komplexität des Befehls. Dazu müssen Sie die Daten nicht lesen. Überprüfen Sie einfach die Größe.

Nein, ddführt keine explizite Überprüfung durch. Wenn Sie eine forensisch überprüfte Kopie Ihres Datenträgers oder eines Teils davon benötigen, verwenden Sie dcfldddiese erweiterte Version des ddvom US-Verteidigungsministerium entwickelten Computer Forensics Lab.

Die einzige Möglichkeit, "sicher" zu sein, besteht darin, einen zusätzlichen Durchlauf zum Lesen und Vergleichen durchzuführen (nachdem die Caches gelöscht wurden).

Außerdem werden ddLese- und Schreibfehler auf dieselbe Weise wie in allen anderen Programmen erkannt. Dies funktioniert, wenn die Laufwerke (und die anderen beteiligten Komponenten) Fehler melden. Für Laufwerke, die Daten stillschweigend akzeptieren, ohne sie tatsächlich zu schreiben, haben Sie Pech.

Ist diese Art von Paranoia gerechtfertigt?

Wenn Sie nicht darauf vertrauen können, dass Ihre Hardware zuverlässig ist, wird es kompliziert ...

Ja, fehlerhafte Hardware kann zufällige Fehlerbits mit einer gewissen Rate von einem Bit pro Megabyte in die Daten einfügen. Dies ist möglich und findet in der Praxis manchmal statt.

Normalerweise verwende ich md5 oder sha1 Hash, um zu überprüfen, ob die Daten intakt sind, indem ich sowohl die Quelle als auch das Ziel erneut lese, zB:

dd if=/dev/sdb of=~/hd_backup
dd if=/dev/sdb | md5sum
dd if=~/hd_backup | md5sum

Dies setzt voraus, dass die Daten viel größer sind als der Dateisystem-Cache. Andernfalls müssen Sie möglicherweise das System neu starten, um die tatsächlichen Daten auf dem Medium und nicht den Cache-Inhalt zu überprüfen, oder ein anderes System dafür verwenden.

Von man dd:

Wenn Sie fertig sind, zeigt dd die Anzahl der vollständigen und teilweisen Eingabe- und Ausgabeblöcke, der abgeschnittenen Eingabedatensätze und der Byte-Austauschblöcke mit ungerader Länge für die Standardfehlerausgabe an.

Ein Teil-Eingabeblock ist einer, bei dem weniger als die Größe des Eingabeblocks gelesen wurde. Ein Teilausgabeblock ist einer, bei dem weniger als die Ausgabeblockgröße geschrieben wurde. Teilausgabeblöcke für Bandgeräte gelten als schwerwiegende Fehler. Andernfalls wird der Rest des Blocks geschrieben. Teilausgabeblöcke für Zeichengeräte erzeugen eine Warnmeldung.

ddÜberprüft, ob die Eingabe- / Ausgabeblockgrößen bei jedem Kopieren eines Blocks übereinstimmen. Wenn dies nicht der Fall ist, wird der Fehler mit einer Warnung oder einem schwerwiegenden Fehler behandelt (überschrieben mit noerror). Deshalb ddfunktioniert praktisch die ganze Zeit.

Es ersetzt jedoch nicht die manuelle Überprüfung der Integrität Ihrer Festplatte. Wenn die Informationen für Sie wertvoll sind, ist Ihre Paranoia gerechtfertigt . Führen Sie nach Abschluss eine manuelle Überprüfung durch dd.