Ich hatte vor Kurzem einen unglaublich kleinen, aber ziemlich großen Festplattenschaden auf einem ESXi-Host, der einige VMs betraf. Es gibt eine Datei, die ich sehr gerne wiederherstellen würde, und natürlich wurde sie irgendwie nicht in meinem regulären Backup gespeichert. Die neuesten Kopien sind 6 Monate alt. Es stellte sich heraus, dass ich die brauche ... ups.
Einzelheiten:
1) Ich habe ddrescue (FANTASTISCHES Tool) in einem bootfähigen ISO von Parted Magic verwendet, um 99,98 % des betreffenden Laufwerks der VM wiederherzustellen. Leider scheinen die Fehler fast ausschließlich auf NEUE Dateischreibvorgänge zurückzuführen zu sein ... also sind dies natürlich genau die Sektoren, die ich am dringendsten wiederherstellen muss.
2) Das Laufwerk gibt IO-Fehler beim Lesen fehlerhafter Sektoren aus, aber es gelingt ihm gelegentlich, einen zuvor fehlerhaften Sektor zu lesen! Eine Wiederherstellung ist also immer noch möglich. Etwas häufiger kommt es zu einer schwerwiegenden Fehlfunktion und das Laufwerk wird heruntergefahren und wieder hochgefahren. Oh, und ungefähr 1/4 dieser Herunterfahren wird nicht wieder hochgefahren. (Harter Aus- und Wiedereinschalten erforderlich, Herunterfahren funktioniert nicht) Und schließlich ist bei fast jedem Lesen fehlerhafter Sektoren ein schönes Klickgeräusch zu hören.
3) Die wichtige VM-Festplatte ist NTFS-formatiert.
4) Ich kann das beschädigte NTFS-Volume (normalerweise) schreibgeschützt mounten und (etwas seltener) zu dem Ordner navigieren, der die benötigte Datei enthält. Allerdings scheint die betreffende Datei immer einen IO-Fehler zu verursachen, wenn ich ein „ls“ des Ordners ausführe. Die anderen Dateien im Ordner verursachen keinen IO-Fehler.
5) Ich habe versucht, ntfsinfo/etc. zu verwenden, was genau das zu sein scheint, was ich brauche, aber die Partition wird dadurch überhaupt nicht geöffnet. (Frustrierend, da „mount“ das normalerweise tut.)
6) Bei der Datei handelt es sich um eine XLS-Datei aus Excel 2003. Daher bin ich mir nicht sicher, ob ich Zeichenfolgen finden kann, nach denen ich das Roh-Disk-Image durchsuchen könnte. (Möglicherweise Teile der 6 Monate alten Version?)
Ich würde wirklich gerne so etwas wie die Möglichkeiten von debugfs nutzen. Aus den Manpages geht jedoch hervor, dass die NTFS-Tools die Arbeit erledigen könnten, wenn man sie nur dazu bringen könnte, die Partition zu öffnen. Insbesondere frage ich mich, ob die IO-Fehler möglicherweise nur in den Metadaten der Datei liegen und ob der Verzeichnisdatensatz so gut wiederhergestellt werden könnte, dass der Dateiinhalt kopiert werden kann. Als letztes Mittel wäre jeder Teil des Dateiinhalts, den ich abrufen kann, großartig.
Ich habe schon früher (relativ einfache) Kernelmodule geschrieben, daher könnte ich ein spezielles NTFS-Modul mit mehr aktivierten (oder hinzugefügten) Debuginformationen kompilieren. (Die Datei ist mindestens ein paar Tage des Herumprobierens wert, um sie wiederherzustellen ... außerdem lerne ich dabei coole Sachen.)
Irgendwelche Hinweise?
BEARBEITEN:
Weitere Informationen zu Laufwerksfehlern:
/var/log/messages zeigt natürlich eine Menge NTFS-fs-Fehler an … aber ich habe mir endlich die Mühe gemacht, die nicht behandelte Sense-Code-Meldung zu übersetzen, die ich normalerweise bekomme: Sense-Schlüssel 0x3, ASC=0x11, ASCQ=0x4. (was sich anscheinend mit „UNBEHOBENER LESEFEHLER – AUTOMATISCHE NEUZUORDNUNG FEHLGESCHLAGEN“ übersetzen lässt).
Wenn das Laufwerk herunterfährt, wird die Meldung „scsi0:“ angezeigt.*BusLogic BT-958 Initialized"-Meldung. Ich bin nicht sicher, ob es der Linux-SCSI-Treiber, der ESXi-Treiber oder das Laufwerk selbst ist, das entscheidet, das Laufwerk herunterzufahren. Wenn es der Linux-Treiber wäre, könnte ich den Treiber vielleicht ändern, um das Herunterfahren zu vermeiden. Diese ganze ddrescue-Sache wird durch diese Herunterfahren, die einen Power-Cycle erfordern, massiv schmerzhafter.
EDIT2:
mithilfe der Protokollmeldung „end_request: I/O error, dev sda, sector 7238859“, gleich nachdem ich das Verzeichnis mit der betreffenden Datei per „ls“ aufgerufen habe, habe ich meine ddrescue-Operation auf diesen Sektor ausgerichtet. Ich plane derzeit, mein Glück zu versuchen und diesen Sektor auf die Live-Festplatte zurückzuSCHREIBEN, wenn dies erfolgreich ist. Vielleicht kann ich mir auf diese Weise langsam den Weg zu der betreffenden Datei wiederherstellen. Dennoch werden die meisten wiederherstellbaren fehlerhaften Sektoren in weniger als 20 Versuchen wiederhergestellt... bei diesem hier sind es bisher über 150... *seufz*
EDIT3:
Der Sektorfehler von „ls“ bei der Datei, die ich brauche, ist völlig unkooperativ (über 1000 Versuche über Nacht und kein Erfolg). Ich hoffe, das sind nur Metadaten, wenn Sie ein „ls“ ausführen? :)
Ich habe zwar den größten Teil einer ddrescue-Kopie, aber die wird nicht gemountet (oder ohne Dateien). Das beschädigte Laufwerk wird meistens korrekt gemountet ... vielleicht zwingen E/A-Fehler auf dem beschädigten Laufwerk das Mounten, um auf das funktionierende Spiegelbild zurückzugreifen?
** EDIT4:**
Ich habe es vorerst aufgegeben und warte auf weitere Vorschläge. Ich habe das Laufwerk entfernt und die Box neu aufgebaut. Ich werde das Laufwerk behalten, falls etwas passiert.
Antwort1
Ein paar Anmerkungen aus meiner Erfahrung:
- (die Ursache)Wenn Sie bei Festplattenzugriffen ein ungewöhnliches Geräusch hören und die Probleme nicht nur an (mehr oder weniger) zufälligen Stellen auf der Festplatte auftreten, liegt die Ursache höchstwahrscheinlich an der Festplattenoberfläche (nicht an der Elektronik) – das ist leider das traurige Szenario. Wenn es „nur“ an der Elektronik gelegen hätte, hätten Sie möglicherweise eine Chance gehabt, die meisten oder sogar alle Ihrer Daten wiederherzustellen.
- (schlechte Sektoren)Wenn Sie dies nicht bereits getan haben, suchen Sie im Internet nach dem bootfähigen Diagnose-/Wiederherstellungstool des Festplattenherstellers, laden Sie es herunter, booten Sie es, führen Sie einen ausführlichen Test durch und lassen Sie es versuchen, fehlerhafte Sektoren neu zuzuordnen – das ist die beste der kostenlosen Methoden. Beachten Sie, dass fehlerhafte Sektoren dazu neigen, größer zu werden. Selbst wenn Sie also einen Teil Ihrer Datei nach etwa dem 2314. Leseversuch noch abfangen, besteht die Möglichkeit, dass durch diese Versuche nur benachbarte fehlerhafte Sektoren größer geworden sind, wodurch die Chance auf eine Wiederherstellung anderer Teile der Datei sinkt.
- (NTFS wiederherstellen)Nichts kann ein NTFS-Dateisystem so gut reparieren wie die nativen Tools von MS Windows. Wenn das NTFS-Image nicht mountbar ist (stellen Sie außerdem sicher, dass Sie versucht haben, die Partition zu mounten, nicht die gesamte Festplatte!), können Sie Dinge wie
testdisk
unter Linux versuchen, aber wenn das nicht klappt, kann Windowschkdisk
helfen. Wenn Sie Windows unter einer virtuellen Maschine installiert haben, können Sie das von erhaltene Rohimageddrescue
in ein von dieser virtuellen Maschine unterstütztes Format (wieVDI
oderVMDK
) konvertieren, es der VM hinzufügen und Windows im Befehlszeilenmodus booten, um das Dateisystem zu reparieren.Wenn Sie VirtualBox verwenden, ist der Befehl zum Konvertieren eines solchen ImagesVBoxManage convertfromraw <filename> <outputfile>
optional, um--format VDI|VMDK|VHD
das angegebene Ausgabeformat zu erhalten.
Antwort2
Dies kann auf Ihren Fall zutreffen oder auch nicht, aber eine letzte Möglichkeit ist der „Gefriertrick“. SieheDaten von einer beschädigten Festplatte wiederherstellen: Der „Freezer-Trick“für eine Diskussion der Methode.