Um meine obigen Ausführungen zu vervollständigen (tut mir leid für die formalen Unannehmlichkeiten / Inkonsistenzen): Ich würde sagen, dass es sich gelohnt hat, obwohl ich nicht recht verstehe, warum. Der zweite Versuch, nach einer Ext4-Partition wiederherzustellen, hatte zu Beginn eine deutlich höhere Kopierrate (durchschnittlich etwa 90 MB / s, während ich beim ersten Versuch, der auf einer NTFS-Partition wiederhergestellt wurde, bestenfalls nur etwa 50 MB / s hatte). und keine fehler oder sogar verlangsamungen. Aber dann, nachdem ich etwa 165 GB (also früher als zuvor) kopiert hatte, wurde es sehr instabil und verlangsamte sich zu einem Kriechen, machte erneut klickende und surrende Geräusche (es war eine sehr heiße Zeit, die nicht half - ich versuchte es abzukühlen.) Verwenden Sie unten ein Laptop-Kühlpad und darüber ein Gefrierpaket, das etwa jede Stunde gewechselt wird.
Hier ist eine ddrescueviewKarte der ersten Wiederherstellung:
Es gibt ein interessantes Muster: Streifen leicht wiederherstellbarer Daten wechseln sich mit sehr langsamen oder unlesbaren Daten ab. Nach allem, was ich weiß, scheint es zu sein, dass ein Kopf mit einer Platte in Kontakt kam, die Oberfläche beschädigt und magnetischen Staub freigesetzt hat, der sich dann mit der Zentrifugalkraft ausbreitet. Und da sich die Servospur (die wesentliche Informationen für den Startvorgang enthält) am äußeren Rand der Festplatte befindet (ein 3,5-Zoll-Hitachi-1-TB-Laufwerk), hat dieser Staub möglicherweise etwas erreicht, was den Zugriff erschwert. was die häufigen Klickgeräusche beim Start erklären könnte (korrigieren Sie mich, wenn ich falsch liege.)
Hier ist eine ddrescueviewKarte der zweiten Erholung:
So wurde die Festplatte sehr instabil und die Wiederherstellung nach etwa 165 GB zunehmend schwieriger. Vorher war die Kopierrate jedoch konstant hoch, und es wurden keine Bereiche übersprungen. Ich habe die ddru_ntfsbitmapMethode später für die letzten Versuche verwendet, sodass der freie Speicherplatz meist übersprungen wurde.
Hier ist eine ddrescueviewKarte der Protokolldatei, die mit erstellt wurde ddru_ntfsbitmap, und zeigt die Bereiche der Festplatte mit den tatsächlichen Daten in Grün und den freien Speicherplatz in Grau:
Glücklicherweise befanden sich die meisten Daten im ersten Quartal und wurden erfolgreich wiederhergestellt. Jetzt muss ich noch die guten Teile dieser beiden Bilder kombinieren und die tatsächlichen Dateien extrahieren, wahrscheinlich mit R-Studio (beste Datenwiederherstellungssoftware, die ich ausprobiert habe).
Was ich später herausfand, war interessant und merkwürdig in Bezug auf meine ursprüngliche Frage (Ich hätte sagen müssen, dass ich dies gemäß den formalen Regeln als Kommentar hätte verwenden sollen, aber es wäre zu lang gewesen 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 dieses Image 1 auf die NTFS-Partition zu kopieren, was mit einer sehr hohen Rate (Eingabe und Ausgabe) hätte erfolgen sollen auf einer gesunden 2-TB-HDD), aber ich habe eine Geschwindigkeit von, wissen Sie was, im Durchschnitt nur 660 KB / s!
Verwendeter Befehl (Protokolldatei für Image 2 als Domänenprotokolldatei verwendet):
ddrescue -m [image2.log] [image2] [image1] [image1.log] Bildschirmfoto:
Also stoppte ich und tat das Gegenteil: Ich kopierte die geretteten Bereiche in Image 1 (NTFS), die in Image 2 fehlten, in Image 2 (Ext4) - und nun betrug die Kopierrate etwa 43000 KB / s oder 43 MB / s im Durchschnitt (vielleicht etwas langsamer als das, was für eine Kopie auf derselben Festplatte erwartet werden sollte, für eine Seagate 2 TB, die eine maximale Schreibgeschwindigkeit von etwa 200 MB / s hat, also etwa 100 MB / s erreichen sollte) Kopieren von einer Partition zur anderen, aber immer noch fast 100 × besser als beim ersten Versuch). Was wäre die Erklärung für eine so große Diskrepanz?
Befehl verwendet:
ddrescue -m [image2.log] [image2] [image1] [image1.log] Bildschirmfoto:
Ich habe festgestellt, dass die Image-Dateien auf beiden Partitionen eine "Größe auf der Festplatte" hatten, die der tatsächlich geschriebenen Datenmenge entsprach, sehr weit von der Gesamtgröße (1 TB oder 931,5 GB) entfernt, obwohl ich nicht t Verwenden Sie den -SSchalter ("sparse write für Ausgabedateien verwenden"). Bild 2 (nach Fertigstellung mit extra geretteten Bereichen aus Bild 1) hat eine "Größe auf Festplatte" von 308,5 GB, während Bild 1 eine "Größe auf Festplatte" von 259,8 GB hat. Könnte es mit der langsamen Kopierrate zusammenhängen, wenn der Linux-NTFS-Treiber Probleme mit spärlichen Schreibvorgängen hat? Und wie kam es, dass nicht die gesamte Größe zugewiesen wurde, sobald Sektoren am Ende geschrieben wurden, wenn man bedenkt, dass ich diesen -SSwitch nicht verwendet habe ?
Ich habe -pam Anfang des Prozesses versucht, den Schalter („Vorbelegung“) zu verwenden, und dachte, dass es „sauberer“, einfacher und einfacher zu handhaben ist, falls etwas schief geht (falls die Wiederherstellung wiederhergestellt werden muss). ..), aber ich musste aufhören, da es viel zu lange war und ich wollte so schnell wie möglich anfangen. Dann dachte ich mir, dass der -RSwitch ("reverse") vorübergehend die allerletzten Sektoren in die Ausgabedatei schreiben würde, wodurch die volle Größe wie gewünscht zugewiesen wird. Dies führte zwar zu einer Vergrößerung der Ausgabedatei auf 931,5 GB, aber die „Größe auf der Festplatte“ war in der Tat viel geringer (ich habe es später bemerkt, als ich auf die für diese Wiederherstellung verwendete Festplatte unter Windows zugegriffen habe und die ungewöhnlich hohe Menge an freiem Speicherplatz sah) Platz).
________________
Ich verstehe immer noch nicht, wie der zweite Wiederherstellungsversuch für die ersten 100 GB ein so viel besseres Ergebnis erzielen konnte, obwohl der Gesundheitszustand der Festplatte inzwischen zurückgegangen ist.
Übrigens sollte das Wort "Festplatte" auf Windows- und Linux-Systemen ebenfalls ersetzt werden, da es Datenspeichereinheiten gibt, die keine "Festplatten" sind.