ddrescue sehr langsam, schreibt auf NTFS – lohnt sich jetzt die Umstellung auf Ext4?

Question

Vor zwei Tagen habe ich mit der Wiederherstellung einer defekten 1-TB-Festplatte begonnen, die mir in der Hoffnung ausgehändigt wurde, dass ich den Großteil davon günstig retten könnte.

Zuerst verhielt es sich unregelmäßig, wurde oft plötzlich getrennt und machte beängstigende Geräusche, wobei die Kopiergeschwindigkeit zwischen einigen KB pro Sekunde und etwa 50 MB pro Sekunde schwankte (es war ein heißer Tag, ich versuchte, eine Überhitzung zu verhindern, indem ich ein Laptop-Kühlpad darunter und einen Kühlblock darüber legte, den ich etwa jede Stunde wechselte). Dann, im Laufe des ersten Abends, wurde es stabiler, aber die durchschnittliche Kopiergeschwindigkeit ging deutlich zurück, auf etwa 3-4 MB/s. Jetzt, nachdem ich 250 GB wiederhergestellt habe, bin ich im Durchschnitt auf etwa 400 KB/s runter, was quälend langsam ist (zumindest scheint es nicht weiter zu sinken).

Meine Fragen sind also:

• Ich mache diese Wiederherstellung auf einer NTFS-Partition, die, wie ich ziemlich spät im Prozess gelesen habe (aufdieser französische Reiseführer), wird nicht empfohlen, da es die Wiederherstellung erheblich verlangsamen kann. Ist das (immer noch) so und wenn ja, warum?
  • Oder gehört das der Vergangenheit an, als der NTFS-Treiber für Linux noch nicht ausgereift genug war? (Ich verwende die neueste Knoppix-Live-DVD, die ich auf eine Speicherkarte kopiert habe, da das Booten von einer DVD-RW nicht erfolgreich war.)
• Lohnt es sich, die Partition zu diesem Zeitpunkt in ein natives Linux-Format wie Ext4 zu konvertieren? Ich meine, würde sich dadurch die Kopiergeschwindigkeit deutlich verbessern?
  • Oder ist es normal, dass eine solche Verlangsamung bei einem ausgefallenen Laufwerk nach dem ersten Durchgang auftritt, bei dem die meisten „gesunden“ Sektoren bereits wiederhergestellt wurden? (Die SMART-Parameter verschlechtern sich, das „Testergebnis der Selbsteinschätzung des Gesamtzustands“ änderte sich von „BESTANDEN“ zu „NICHT BESTANDEN“, die Anzahl der neu zugewiesenen Sektoren stieg von 144 auf 1360.)
• Kann ich sonst noch etwas tun, um die Wiederherstellungsrate und/oder Wiederherstellungsgeschwindigkeit zu verbessern?
• Gibt es Optionen, ddrescuedie ich mit echtem Nutzen ausprobieren könnte?

Die ersten Durchläufe habe ich mit diesem Befehl gemacht:

ddrescue -n -N -a500000 -K1048576 -u /dev/sdc /media/sda1/Hitachi1TB /media/sda1/Hitachi1TB.log

(Die -n& -N-Schalter umgehen angeblich die Scraping- und Trimming-Phasen – obwohl ich nicht sicher bin, an welchem ​​Punkt des Prozesses diese Aktionen vom Programm versucht werden und ob es wirklich sinnvoll ist, sie zu umgehen. Dann habe ich eine Mindestkopiergeschwindigkeit von 500.000 Bytes pro Sekunde und einen Wert von 1 MB für „Anfangsgröße, die bei Lesefehlern übersprungen werden soll“ angegeben und versucht, die Bereiche, die noch intakt oder leicht zugänglich sind, so schnell wie möglich zu kopieren. Das -usteht für „unidirektional“: Bei einer früheren Wiederherstellung mit einer anderen Festplatte -Rschien das Kopieren in umgekehrter Richtung mit dem Schalter die Sache zu verbessern, aber bei dieser hier scheint es Chaos anzurichten, und mit diesem Schalter läuft es anscheinend stabiler.)

Nachdem ein Durchgang abgeschlossen war, habe ich die meisten dieser Parameter entfernt und nur den beibehalten . Ich habe irgendwann -uden Schalter ausprobiert („direkten Festplattenzugriff verwenden“), aber dann wurde nichts kopiert, die „Fehlergröße“ wuchs sehr schnell.-d

Answer 1

Um meine obigen Kommentare zu vervollständigen (sorry für die formalen Unannehmlichkeiten/Inkonsistenzen): Ich würde sagen, dass es sich gelohnt hat, auch wenn ich nicht ganz verstehe, warum. Der zweite Versuch, die Wiederherstellung auf eine Ext4-Partition, hatte am Anfang eine deutlich höhere Kopierrate (durchschnittlich etwa 90 MB/s, während ich beim ersten Versuch, der Wiederherstellung auf eine NTFS-Partition, bestenfalls etwa 50 MB/s hatte) und keine Fehler oder gar Verlangsamungen. Aber dann, nach dem Kopieren von etwa 165 GB (also früher als zuvor), wurde es sehr instabil und wurde langsam, machte wieder Klick- und Surrgeräusche (es war eine sehr heiße Zeit, was nicht half – ich versuchte, es so weit wie möglich abzukühlen, indem ich ein Laptop-Kühlkissen darunter und eine Kühltasche darüber legte, die ich etwa jede Stunde wechselte); ich versuchte es immer wieder (manchmal ging es für ein paar Sekunden wieder auf eine Rate von 120 MB/s zurück und dann wieder auf 0), aber ich musste es nach einer Weile aufgeben.

Hier ist eine ddrescueviewKarte der ersten Bergung:

Es gibt ein interessantes Muster: Streifen leicht wiederherstellbarer Daten wechseln sich mit sehr langsamen oder nicht lesbaren Daten ab.[Soweit ich weiß, deutet dies darauf hin, dass ein Kopf mit einer Platte in Kontakt kam, wodurch die Oberfläche beschädigt und magnetischer Staub freigesetzt wurde, der sich dann durch die Zentrifugalkraft verteilte. Und da sich die Servospur (die wichtige Informationen für den Startvorgang enthält) am äußeren Rand der Festplatte befindet (es handelt sich um eine 3,5-Zoll-Hitachi-Festplatte mit 1 TB), könnte ein Teil dieses Staubs dorthin gelangt sein und den Zugriff erschwert haben, was die häufigen Klickgeräusche beim Start erklären könnte.](Korrigieren Sie mich, wenn ich falsch liege.) => [EDIT 20200501] Das war falsch, tatsächlich weist dieses Muster normalerweise darauf hin, dass ein Kopf des Laufwerks vollständig ausgefallen ist und nichts mehr liest. Die Daten auf den Platten sind zu diesem Zeitpunkt möglicherweise noch lesbar, aber dazu wäre der Austausch der Kopfstapelbaugruppe erforderlich, was nur ein spezialisiertes Datenwiederherstellungslabor sicher durchführen kann.

Hier ist eine ddrescueviewKarte der zweiten Bergung:

Die Festplatte wurde also ab ca. 165 GB sehr instabil und die Wiederherstellung zunehmend schwieriger, vorher war die Kopiergeschwindigkeit aber konstant hoch, ohne dass Bereiche übersprungen wurden. Ich habe die ddru_ntfsbitmapMethode später bei den letzten Versuchen verwendet, sodass der nicht zugeordnete Speicherplatz größtenteils übersprungen wurde.

Hier ist eine ddrescueviewKarte der mit erstellten Protokolldatei ddru_ntfsbitmap, die die Bereiche der Festplatte mit tatsächlichen Daten in Grün und den freien Speicherplatz in Grau anzeigt:

Glücklicherweise befanden sich die meisten tatsächlichen Daten im ersten Viertel und konnten erfolgreich wiederhergestellt werden. Jetzt muss ich noch die guten Teile dieser beiden Bilder kombinieren und die eigentlichen Dateien extrahieren, wahrscheinlich mit R-Studio (der besten Datenwiederherstellungssoftware, die ich ausprobiert habe).

---

Im Zusammenhang mit meiner ursprünglichen Frage habe ich später etwas Interessantes und Merkwürdiges herausgefunden (den formellen Regeln zufolge hätte ich dies wohl als Kommentar verfassen sollen, aber es wäre zu lang geworden und ich hätte keine Screenshots bereitstellen können).

Ich habe versucht, die geretteten Bereiche von Image 2 auf der Ext4-Partition, die in Image 1 fehlten, in Image 1 auf der NTFS-Partition ^{1} zu kopieren , was mit einer sehr hohen Geschwindigkeit hätte erfolgen sollen (Ein- und Ausgabe erfolgten auf einer intakten 2-TB-Festplatte), allerdings habe ich nur eine Durchschnittsgeschwindigkeit von 660 KB/s erreicht und damit sehr nahe an der Geschwindigkeit der ersten Wiederherstellung zu einem späteren Zeitpunkt gelegen, als ich besorgt genug war, um diese Frage überhaupt erst zu stellen ...

Verwendeter Befehl (Protokolldatei für Bild 2, die als Domänen-Protokolldatei verwendet wird):

ddrescue -m [image2.log] [image2] [image1] [image1.log]

Bildschirmfoto:

Also habe ich aufgehört und das Gegenteil gemacht: Ich habe die geretteten Bereiche in Image 1 (NTFS), die in Image 2 (Ext4) fehlten, in Image 2 kopiert – und jetzt lag die Kopiergeschwindigkeit bei durchschnittlich 43.000 KB/s oder 43 MB/s (vielleicht etwas langsamer als man für eine Kopie auf derselben Festplatte erwarten würde, denn eine Seagate 2 TB hat eine maximale Schreibgeschwindigkeit von fast 200 MB/s, sollte also bei einer Kopie von einer Partition auf die andere etwa 100 MB/s erreichen können, aber immer noch fast 100-mal besser als beim ersten Versuch). Was wäre die Erklärung für eine so enorme Diskrepanz?

Verwendeter Befehl (Protokolldatei für Bild 1, die als Domänen-Protokolldatei verwendet wird):

ddrescue -m [image1.log] [image1] [image2] [image2.log]

Bildschirmfoto:

Mir fiel auf, dass die Imagedateien auf beiden Partitionen eine „Größe auf der Festplatte“ ^{2} hatten , die der tatsächlich geschriebenen Datenmenge entsprach und sehr weit von der Gesamtgröße (1 TB oder 931,5 GB) entfernt war, obwohl ich den Schalter -S(„sparse writes für Ausgabedateien verwenden“) nicht verwendet hatte. Image 2 (nachdem es mit zusätzlichen geretteten Bereichen aus Image 1 vervollständigt wurde) hat eine „Größe auf der Festplatte“ von 308,5 GB, während Image 1 eine „Größe auf der Festplatte“ von 259,8 GB hat. Könnte es mit der langsamen Kopiergeschwindigkeit zusammenhängen, wenn der Linux-NTFS-Treiber irgendwie Probleme mit spärlichen Schreibvorgängen hat? Und wie kommt es, dass die gesamte Größe nicht zugewiesen wurde, sobald Sektoren am Ende geschrieben wurden, wenn man bedenkt, dass ich diesen -SSchalter nicht verwendet habe?

Ich habe versucht, den Schalter („preallocate“) ganz am Anfang des Vorgangs zu verwenden -p, weil ich dachte, das wäre „sauberer“, direkter und einfacher zu handhaben, falls etwas schiefgehen sollte (wenn die Wiederherstellung wiederhergestellt werden muss...), aber ich musste aufhören, weil es viel zu lange dauerte und ich so schnell wie möglich loslegen wollte (anscheinend schreibt es tatsächlich leere Daten, anstatt einfach die erforderlichen Sektoren zuzuweisen). Dann dachte ich, dass durch die -Rvorübergehende Verwendung des Schalters („reverse“) die allerletzten Sektoren in die Ausgabedatei geschrieben würden, wodurch die volle Größe zugewiesen würde, wie ich es beabsichtigt hatte; dies führte tatsächlich dazu, dass die Größe der Ausgabedatei auf 931,5 GB zunahm, aber die „Größe auf der Festplatte“ war tatsächlich viel geringer (das bemerkte ich später, als ich unter Windows auf die für diese Wiederherstellung verwendete Festplatte zugriff und den ungewöhnlich hohen freien Speicherplatz sah).
________________
{1} Ich verstehe immer noch nicht, wie der zweite Wiederherstellungsversuch für die ersten 100 GB oder so ein so viel besseres Ergebnis erzielen konnte, obwohl sich der Gesundheitszustand der Festplatte in der Zwischenzeit verschlechtert hatte. [EDIT 20200501] => Es liegt möglicherweise an dem a500000zuerst verwendeten Parameter, der Bereiche übersprang, bei denen die Lesegeschwindigkeit unter dem Schwellenwert von 500 KB/s lag. Ohne diese Option wurden langsamere Bereiche beim zweiten Mal sofort gelesen. Tatsächlich waren diese langsameren Bereiche mit einem schwachen Kopf verbunden, daher ist es immer noch ein Rätsel, warum dieser fehlerhafte Kopf beim zweiten Mal so viele Daten abrufen konnte, obwohl er bereits Anzeichen einer Fehlfunktion gezeigt hatte. Ich lerne immer noch ...

{2} Übrigens sollte das Wort „Disk“ sowohl auf Windows- als auch auf Linux-Systemen ersetzt werden, da es Datenspeichereinheiten gibt, die keine „Disks“ sind...

Answer 2

1. Möglicherweise möchten Sie zuerst das Disk-Image kopieren mitddBefehl

   sudo dd bs=[Blockgröße] Anzahl=[AnzahlBlöcke] if=[Eingabedatei] von=[Ausgabedatei]

Wo

[in_file] – kann die defekte Festplatte sein, z. B. /dev/sdd2

[out_file] – Speicherort der Ausgabebilddatei.

2. Mounten Sie das Image und versuchen Sie, es wiederherzustellen.