Ich hatte vor kurzem einen Freund mit einer neuen internen Hitachi-Desktop-Festplatte (2 TB, 32 MB, 7200 U/min, 3,5 Zoll, SATA, 6,0 Gb/s) mit Win7 Pro-Betriebssystem, die von Windows als defekt gemeldet wurde. Er bat mich, sie wiederherzustellen und die Festplatte auszutauschen. Dies war keine Boot-Festplatte. Es blieben noch ein paar Tage, um sie an den Verkäufer zurückzusenden.
Ich konnte mit nichts in einem neuen PC (mit einem anderen, nachweislich funktionierenden SATA-Controller und SATA-Daten- und Stromkabeln) darauf zugreifen.
Interessanterweise meldete Hitachis DFT, dass alles in Ordnung sei: SMART-Status: Gesund
Testprotokoll
ReadErrStat : Done
Result : Pass
SMART QT : Done
Result : Pass
Obwohl 3 Windows-Ereignisse denselben SMART-Fehler anzeigen. Beschreibung: Der Treiber hat erkannt, dass das Gerät \Device\Harddisk3\DR3 einen Ausfall vorhergesagt hat. Sichern Sie umgehend Ihre Daten und ersetzen Sie Ihr Festplattenlaufwerk. Ein Ausfall könnte unmittelbar bevorstehen.
Ich habe ddrescue 1.18.1 auf der System Rescue-CD verwendet.
Da die Festplatte neu war, ging ich davon aus, dass sich alle Daten/Dateien im ersten Viertel der Festplatte befinden würden. ddrescue brauchte etwa 25 Stunden, um sich durch die 2-TB-Festplatte zu wühlen und auf eine neue 2-TB-Festplatte zu schreiben (ich vermute, einige wissen jetzt, was mein Problem sein wird). Ich hatte keine größeren Festplatten.
ddrescue -n -f /dev/sdb /dev/sdc resq.log
ddrescue konnte alle Dateien bis auf 347 (ca. 0,5 %) wiederherstellen, meldete jedoch, dass der Vorgang nicht ordnungsgemäß abgeschlossen werden konnte, da auf dem Ziellaufwerk nicht genügend Speicherplatz vorhanden war. Die langsame Übertragungsrate sowie die steigende Anzahl nicht wiederhergestellter Dateien endeten etwa ein Viertel des Wiederherstellungsprozesses, was darauf hindeutet, dass die Datendateien – oder zumindest die meisten – bereits vorhanden waren und nun buchstäblich Neuland wiederhergestellt wurde.
Beide waren NTFS-formatiert und bestanden aus einzelnen Partitionen der gesamten Laufwerke (das neue war eine neue 2-TB-Festplatte von Toshiba).
Unter Linux kann ich das wiederhergestellte Laufwerk weder mounten, um es zu kopieren, noch es anzeigen. Es tritt immer wieder ein NTFS-Formatfehler auf.
Ich möchte nicht sehen, ob auf einem Windows-Betriebssystem etwas sichtbar ist, da diese dazu neigen, Reparaturen anzubieten, was ich aber nicht möchte.
Um die Sache noch schlimmer zu machen, kaufte ich ein 4-TB-Laufwerk, formatierte es mit GPT und begann, ddrescue zu wiederholen. Die fehlerhafte Festplatte versagte jedoch bereits nach weniger als 10 % des Vorgangs komplett.
Ich habe das ddrescue-Handbuch sowie mehrere Foren gelesen und kann keine Anweisungen finden, wie ich das „vollständige“ Ziellaufwerk reparieren kann, damit es zugänglich ist. Ich möchte keine Fehler machen, die die Daten weiter beschädigen könnten. Hat jemand eine Idee zur Rettung/Reparatur, damit ich eine Kopie erstellen und dann sehen kann, was wiederhergestellt wurde und wie die Dinge stehen?
Antwort1
Was meinen Sie mit „ddrescue hat alle 347 Byte großen Dateien wiederhergestellt“? ddrescue sollte eine 32-Bit-Kopie der Festplatte erstellen, sodass es sich nicht mit Dateien befasst.
Es ist unklar, wo Ihr Rettungsprotokoll ist/war – haben Sie es noch?
Ich wäre geneigt, eine kleine Kopie von der guten 2-TB-Festplatte auf die 4-TB-Festplatte zu machen.
Ich würde dann versuchen, erneut eine ddrescue-Operation vom fehlerhaften 2-TB-Laufwerk auf das einwandfreie 4-TB-Laufwerk durchzuführen – aber dieses Mal mit dem Schalter -R, damit versucht wird, vom Ende der Festplatte aus wiederherzustellen (weil die 2-TB-Laufwerke meiner Meinung nach leicht unterschiedliche Größen hatten und daher das Endbit nicht erhalten wurde). Wenn Sie Zugriff auf die Protokolldatei haben, versuchen Sie, diese ebenfalls zu verwenden, da dies das Leben wahrscheinlich etwas einfacher machen wird – aber es ist wohl nicht kritisch.
Ich würde dann prüfen, ob ich unter Linux auf die Daten (von der 4-GB-Festplatte) zugreifen kann. Wenn nicht – und ich gehe davon aus, dass dies nicht möglich sein wird – würde ich es unter Windows versuchen und prüfen, ob es die Daten lesen kann.
Wenn dies fehlschlägt, verwende ich Photorec auf dem guten 2-TB-Laufwerk, um alles zu schaffen, was ich kann, und umgehe dabei NTFS.