NTFS-Partition nicht mehr zugänglich, 3 MFT-Datensätze beschädigt, Möglichkeit zur Behebung dieser Probleme?

730
GabrielB

Ich habe eine 2 TB Seagate ST2000DM001-Festplatte mit einer NTFS-Partition. Ich hatte es seit Monaten nicht mehr verwendet, als ich es wieder eingesteckt hatte, war diese Partition unerklärlicherweise unzugänglich geworden: Der Buchstabe des Volumes wird in Windows Explorer angezeigt, aber die Größe der Partition wird nicht mehr erkannt. Wenn ich versuche, sie zu öffnen, ist ein Fehler aufgetreten. Es erscheint im Storage Manager als „RAW“. CHKDSK gibt die Analyse sofort auf und gibt eine Fehlermeldung aus, die besagt, dass die Version und der Status des Volumes nicht ermittelt werden können.

Wenn ich dieses Laufwerk jedoch mit R-Studio öffne, erscheint die Partition sofort mit der richtigen Größe (es ist nicht einmal ein Scanvorgang erforderlich). Ich kann sie öffnen und auf alle Dateien zugreifen, die beim letzten Mal verwendet wurden der gesamte Verzeichnisbaum und der Inhalt der Dateien scheint, soweit ich sehen kann, zu 100% korrekt zu sein. Wenn ich das gesamte Laufwerk mit WinHex öffne, erkennt es die Partition korrekt und zeigt die Dateien und Ordner mit ihrem korrekten Inhalt an. Ich habe auch zwei Defragmentierungssoftware getestet (nur im Analysemodus): MyDefrag kann den Inhalt der Partition auflisten und liefert gültige Informationen für jeden mit dem Mauszeiger darübergefahrenen Block (Dateiname, Größe, LBA ...); aber Defraggler kann nicht. Ich habe es auch mit DMDE geöffnet: Wie R-Studio kann der Inhalt der Partition sofort erkannt werden.MFT-Datensätze 1, 2, 3 ; Diese entsprechen normalerweise: $ MFTMirr, $ LogFile und $ Volume, drei wichtigen Systemdateien, die tatsächlich im Verzeichnis "$ MetaData" fehlen. Wenn ich zu R-Studio zurückkehre, sehe ich, dass diese Dateien auch im Verzeichnis "Metafiles" fehlen. Wenn ich den Beginn der MFT mit WinHex untersuche, kann ich sehen, dass der MFT-Datensatz 0 in Ordnung ist (er zeigt auf die MFT selbst), aber dann sind die MFT-Datensätze 1, 2 und 3 beschädigtsind sie mit "FF" (hex) / "ÿ" (ASCII) gefüllt. Und das Merkwürdige ist, dass der MFT-Spiegel (den ich noch mit WinHex unter Verwendung eines alten Volume-Snapshots lokalisieren kann, bevor das Problem aufgetreten ist) und seine Position ebenfalls von R-Studio in seinem Partitionseigenschaftsfenster angezeigt wird, anscheinend sowohl das MFT als auch MFTMirr haben ihre LBA in den Boot-Sektor geschrieben.) Es hat genau das gleiche Korruptionsmuster: Der erste Datensatz ist in Ordnung, dann werden die nächsten drei mit "FF" gefüllt.

Ich vermute, dass auf die Partition nicht zugegriffen werden kann, da diese drei MFT-Einträge fehlen und die entsprechenden Dateien nicht gefunden werden können. Und CHKDSK muss mindestens diese Dateien benötigen, um ordnungsgemäß zu funktionieren. Wie konnte das passieren? Wie könnten sowohl die MFT als auch ihre Spiegelung (mit ist eigentlich nur eine Kopie der ersten 4 Datensätze, aber in diesem speziellen Fall hätte es ausreichen müssen, um das Problem zu beheben, da die 3 beschädigten Datensätze zu den 4 Datensätzen gehören) gleiche Zeit ?
Und wie könnte ich diese fehlenden MFT-Datensätze reparieren / wiederherstellen?, um die Partition zu fixieren, anstatt alle Dateien zu extrahieren (was ich bereits als Sicherheitsmaßnahme getan hatte), die Partition neu zu formatieren und sie zurück zu übertragen? Ich konnte die gültigen Datensätze von einer anderen Partition kopieren und die Variablenwerte ändern, wobei ich die Vorlage wusste, aber bisher konnte ich nur die Zeitstempel identifizieren (die ich aus anderen Systemdateien auf derselben Partition kopieren kann, da sie alle erstellt werden) Gleichzeitig kann ich die Felder, die die Größe des Clusters angeben, noch nicht finden. Ich fand auch heraus, dass $ Volume, eine residente Datei (die sich vollständig in der MFT befindet), den eindeutigen Identifikator der Partition enthält, der hier die problematischste Hürde sein kann: Sollte es unbedingt derselbe sein wie zuvor, damit die Partition ordnungsgemäß funktioniert erkannt, und wenn ja, ist es irgendwo im System gespeichert, oder kann es zufällig ausgewählt werden, und wenn ja, gibt es ein bestimmtes Muster, dem es sich anpassen muss? Die Informationen über die grundlegende Struktur von MFT-Datensätzen scheinen knapp zu sein oder unter Tausenden von Seiten mäandrierender Foren-Threads oder Artikeln mit einem zu großen Umfang zu finden, um in einem solchen Fall von Nutzen zu sein.

The partition opened in DMDE, three error warnings WinHex showing what should be the MFT record of $Volume The valid MFT record of $Volume on another partition

Ich habe das Problem ausführlicher mit HDDGuru beschrieben, hatte jedoch keine relevante Antwort auf die Frage "Wie kann ich das Problem beheben?" (Regelmäßige Mitwirkende dort sind sehr gut informiert, wenn es um Hardware- / Firmware-Fehler geht, aber für diese Art von Fehlern logische Fehler scheinen sie ziemlich schnell aufzugeben).
http://forum.hddguru.com/viewtopic.php?f=1&t=36969

2
Zuerst würde ich mir das Laufwerk vorstellen, damit es nicht durch Reparaturen verschlimmert wird. Dann würde ich versuchen, sie auf einem anderen PC oder von einem Live-USB-Gerät aus zu öffnen, da ein Betriebssystem "verwirrt" werden kann, wenn eine Festplatte entfernt wird, ohne ausgeworfen zu werden. Das Betriebssystem könnte falsche Informationen zwischenspeichern. Versuchen Sie es vielleicht unter einem anderen Betriebssystem, das möglicherweise fehlender MFT toleriert. Dies sind keine Korrekturen, aber schnelle Tests lassen sich leicht implementieren. DrMoishe Pippik vor 5 Jahren 0
Lesen Sie https://www.cgsecurity.org/wiki/Advanced_NTFS_Boot_and_MFT_Repair und diesen Abschnitt ** Reparieren Sie eine NTFS-MFT ** und prüfen Sie, ob testdisk Ihnen hilft. cybernard vor 5 Jahren 0
Das ist super komisch. Der MFT-Spiegel (der eigentlich kein Spiegel ist) befindet sich an einem festen Ort innerhalb des Dateisystems (er beginnt bei der Hälfte) und kann vom MFT selbst neu aufgebaut werden. Es ist wirklich merkwürdig, dass `chkdsk` nicht funktioniert. Andrea Lazzarotto vor 5 Jahren 0

1 Antwort auf die Frage

2
GabrielB

So konnte ich das Problem selbst beheben. Ich habe einige Nachforschungen über die Struktur von MFT-Datensätzen im Allgemeinen und die besondere Struktur der 3 beschädigten Datensätze durchgeführt, die ich neu erstellen musste (siehe den verknüpften HDDGuru-Thread für Details), während ich sie auf mehreren gültigen Partitionen untersuchte. Dann habe ich sie im Grunde von einer gültigen Partition in eine temporäre Datei in WinHex kopiert, einige Schlüsselwerte geändert, die sich von einer Partition zur anderen unterschieden, dann die 3072-Byte-Datei direkt auf die Partition kopiert, CHKDSK ausgeführt, die fortfahren und (nach einem Einige Versuche und Fehler) berichteten, dass das Volume keinen Fehler hatte und nun normalerweise auf die Partition wieder zugegriffen werden kann. Ich weiß immer noch nicht wie es passiert ist, aber es ist behoben!

Die Werte, die ich ändern musste, waren:
- die Zeitstempel: Alle Systemdateien haben die gleichen Zeitstempel. Daher habe ich die Zeitstempelfelder des ersten MFT-Datensatzes (der auf den MFT selbst verweist) auf die beschädigte Partition kopiert. - die erste Cluster-LBA für den $ LogFile-Datensatz (ich wusste dank des alten WinHex-Volume-Snapshots, wo er sich befand, ansonsten hätte ich die Datei anhand ihres Headers suchen müssen, um diesen Wert zu erhalten; ihre Standardgröße ist genau 64 MB, oder 67108864 Bytes (auf allen untersuchten Partitionen gleich);
- Bei jedem Datensatz gibt es ein 1-Byte-Feld namens "Fixup" in DMDE, das an drei verschiedenen Stellen vorhanden ist. Dies ist, wie mir jemand im HDDGuru-Thread erklärt hat, "nur eine Überprüfung, um sicherzustellen, dass der Datensatz gültig und nicht beschädigt ist ”Und kann auf einen beliebigen Wert gesetzt werden, solange er in allen drei Instanzen dieses Feldes gleich ist;

- Für den $ Volume-Datensatz (der auch die eigentliche $ Volume-Datei enthält, da diese Datei "resident" ist, dh vollständig in ihrem MFT-Datensatz enthalten ist), musste ich die ursprüngliche 16-Byte-ID (oder "Objektkennung") von finden Das Volume war der schwierigste Teil: Nach einigen erfolglosen Versuchen fand ich diesen Wert in der Datei "tracking.log", im Verzeichnis "System Volume Information" (Ich hatte ihn zuerst auf eine gültige Partition geprüft, der Wert passte dazu das in $ Volume angezeigt wurde, also habe ich das entsprechende Feld aus "tracking.log" auf der beschädigten Partition kopiert und in $ Volume) in das Volume-ID-Feld eingefügt.
- Auch in $ Volume habe ich den Namen des Volumes geändert, um den gleichen Namen wie zuvor zu haben. Dies war jedoch nicht erforderlich. Ich hätte den Namen von der anderen Partition lassen können und ihn später in den Eigenschaften des Volumes ändern können, sobald er wieder verfügbar war (Eigentlich habe ich hier einen kleinen Trick benutzt: Ich habe das Ende des $ Volume-Datensatzes von einer Partition mit dem Namen "TEMP" kopiert). Statt diesen Namen mit "Stockage" zu ändern, da die Partition zuvor aufgerufen wurde, habe ich "Stoc" gesetzt. so dass es die gleiche Anzahl von Zeichen hätte, um einen unerwarteten Versatz zu vermeiden und um sicherzustellen, dass der Wert für "used size" übereinstimmt, da ich die Struktur des Datensatzes noch nicht vollständig verstanden habe);
- Da ich den Namen des Volumes geändert habe, war die Länge des tatsächlich verwendeten Dateisatzes unterschiedlich. Daher musste ich das Feld entsprechend der verwendeten Größe ändern, um dies wiederzugeben und die Konsistenz beizubehalten (ich habe die gleiche "verwendete Größe" wie bei eine von der Partition namens "TEMP");
- Zu Beginn des $ Volume-Datensatzes gab es einen anderen Wert, der in DMDE "LSNlo" genannt wird: Basierend auf meiner Recherche steht "LSN" für "$ LogFile Sequence Number" und es ist ein Hinweis auf die letzte aufgezeichnete Änderung In der $ LogFile-Datei in Bezug auf einen bestimmten Dateisatz in der $ MFT ist dies nicht ausschlaggebend für die Konsistenz, und ich fand heraus, dass die Größe der $ LogFile-Datei in der Regel begrenzt ist, dh alte Datensätze werden regelmäßig gelöscht, da ich das nicht verwendet habe Laufwerk in Monaten, der Datensatz, der dem Wert entspricht, der vor dem Löschen vorhanden war, wurde gelöscht. Daher füge ich nur Nullen in dieses Feld ein.

@DrMoishe Pippik: Aus Sicherheitsgründen habe ich den gesamten Inhalt mit R-Studio auf ein anderes Laufwerk extrahiert, bevor ich dieses In-Place-Update versuchte. Ich habe auch eine Teilsicherung der ersten 5 GB gemacht (was ausreicht, um alle relevanten Dateisystemstrukturen zu enthalten - obwohl betont werden sollte, dass es nicht immer ausreicht, die gesamte MFT zu erhalten, ich habe es auf die harte Tour gelernt !). Ich habe nicht versucht, auf das Laufwerk von einem anderen Computer aus zuzugreifen, aber ich sehe nicht, wie es anders gewesen wäre (auf einem Windows-System ohnehin - vielleicht wäre es auf einem Linux-System trotzdem erkannt und zugänglich gewesen), seit diesen drei MFT-Datensätze wurden in WinHex effektiv gelöscht und das Problem blieb nach einem Neustart bestehen.

@cybernard: Ich habe TestDisk ausprobiert, das war eine meiner ersten Ideen, nachdem ich den SMART-Status (was war und noch in Ordnung ist) überprüft hatte: Er hat die Partition gefunden und konnte die Dateien auflisten (genau wie die anderen von mir genannten Softwares), aber Das Problem konnte nicht behoben werden, da im Falle einer MFT-Korruption nur die ersten vier Datensätze repariert werden können, indem sie aus $ MFTMirr kopiert werden. Diese drei beschädigten Datensätze wurden jedoch ebenfalls in $ MFTMirr auf dieselbe Weise beschädigt .

@Andrea Lazzarotto: Nach meinen Beobachtungen befindet sich $ MFTMirr immer im Sektor 16, also ganz am Anfang der Lautstärke, weit vor der eigentlichen $ MFT, die standardmäßig um die 3 GB-Marke liegt. CHKDSK funktionierte wahrscheinlich nicht, weil $ MFTMirr ebenfalls beschädigt war und daher nicht auf die anscheinend wichtige $ Volume-Datei zugreifen konnte, die ebenfalls gelöscht wurde, da sie Teil des MFT-Datensatzes ist.

Verwandte Probleme