Partitionen auf 3TB Festplatte lassen sich mit testdisk nicht mehr finden

[Ernst@at]

Oder kann ich vielleicht noch mit CHKDSK /f /r noch was ausrichten?

Das kann nur die restlichen 89% des bei 11% abgebrochenen zerstörerischen Werkes vollenden.
Die einzige Möglichkeit besteht in Anwendung eines Rettungstools wie zB GetdataBack for NTFS, sowohl in der derzeitigen als auch unter Verwendung der fehladressierenden Treibervariante. Jede derart gefundene Datei muss auf Gültigkeit des Inhaltes überprüft werden, der könnte auch überschrieben sein.

[Crabman1312]

Also lasse ich von chkdsk auf jeden Fall die Finger, um nicht noch mehr kaputt zu machen.

Mit einem Rettungstool konnte ich bereits einige Daten sehen. Ich bin mir also sicher, dass die Daten noch vorhanden sind. Ob einige Daten (die 11%) wirklich vernichtet sind oder nicht, kann ich natürlich noch nicht sagen. Dafür sind es einfach zu viele Daten. Aber einige relevante Daten der Diplomarbeit, für die ich die ganze Partitionswiederherstellung auf mich nehme, habe ich auch schon wiederfinden können. Leider noch nicht alle.

Ich bin aber inzwischen wieder ganz guter Dinge. Ein bisschen Hoffnung keimt auf, dass ich das Wichtigste irgendwie wiederbekommen kann. Außerdem hat testdisk ja die 3000GB Partition gefunden. Es braucht "nur noch" den BootSektor und die Partitionstabelle neu zu schreiben.

Noch mal zu testdisk: Im Anhang ist das logfile von testdisk, das die Bilder vom vorherigen Post ausführt. Zeile 628 liefert die NTFS Partition mit 3000GB, und in Ziele 705 taucht sie wieder auf, mit der blocksize=4096. Hier ist sie aber als nicht wiederherstellbar gelistet.

Offensichtlich ist testdisk nicht in der Lage, die Partition aus den gesammelten Informationen wiederherzustellen. Würde denn hier ein (10 Tage) DeepSearch helfen?

Hat testdisk vielleicht Probleme mit der Größe der Partition, der blocksize oder der sector size?

[MiamXD]

Hm,also ich stand vor einem ähnlcihen Problem, allerdings war "nur" eine 500gb Partition auf ner 1tb Festplatte weg. Beim Quicksearch wurde sie nicht gefunden(die anderen Partitionen die Windows erkannte aber auch nicht), beim Deep Search wurden mir die Partitionen gleich doppelt(wahrscheinlich wg. Backupheadern?) angezeigt, allerdings war auch jeweils nur eine davon auslesbar(bietet testdisc ja an). Die 10 Tage halte ich aber für deutlich überdimensioniert. Meine 1 TB quicksearch hat irgendwas zwischen 12 und 16 Std gebraucht(bin dabei schlafen gegangen). Und ich habe die 3tb Seagate Platte auch, die ist nicht langsamer als die Samsung die bei mir defekt war. Was evtl hilft: Testdisc überspringt unter Umständen viele Sektoren, wenn die gefundenen Dateien groß sind. Dies kann im voraus nicht abgeschätzt werden, da es, wie bereits erwähnt, nach Dateiheadern sucht.

[Ernst@at]

Ich bin aber inzwischen wieder ganz guter Dinge. Ein bisschen Hoffnung keimt auf, dass ich das Wichtigste irgendwie wiederbekommen kann. Außerdem hat testdisk ja die 3000GB Partition gefunden. Es braucht "nur noch" den BootSektor und die Partitionstabelle neu zu schreiben.

Dir scheint noch nicht ganz klar zu sein, was da passiert ist.
Ich habe hier noch eine andere Kundschaft, wo die Platte in einem externen Gehäuse richtig addressiert wurde, als die Daten draufgespielt wurden. Dann wurde sie intern verbaut, wo alte Treiber den Adressierfehler verursachten. Dateisystem-Fehler erkannt, nach Neustart ist automatisch Datenträgerüberprüfung mit chkdsk durchgelaufen:

Glücklicherweise wurden davor und danach diagnostische Daten erhoben, hier als Beispiel vom Verzeichis (File 1714)
vorher:

File 1714

\für Michael Stephan\

    $STANDARD_INFORMATION (resident)

    $FILE_NAME (resident)

    $FILE_NAME (resident)

    $INDEX_ROOT $I30 (resident)

    $INDEX_ALLOCATION $I30 (nonresident)

        logical sectors [COLOR="Red"]4478220528-4478220535[/COLOR] (0x10aec38f0-0x10aec38f7)

    $BITMAP $I30 (resident)

nachher:

File 1714

\für Michael Stephan\

    $STANDARD_INFORMATION (resident)

    $FILE_NAME (resident)

    $FILE_NAME (resident)

    $INDEX_ROOT $I30 (resident)

    $INDEX_ALLOCATION $I30 (nonresident)

        logical sectors [COLOR="Red"]4967107168-4967107175[/COLOR] (0x128100a60-0x128100a67)

    $BITMAP $I30 (resident)

Ein Ordner, der über der 2TiB-Grenze lag, wurde durch die Fehladressierung nicht gefunden, daher ein neuer über der 2TiB Grenze angelegt, und damit irgendwas durch die Fehladressierung 2TiB tiefer überschrieben.

Nach Behebung des Adressierungsfehlers steht jetzt natürlich der Inhalt des Ordners nicht über 2TiB und wird daher wieder nicht gefunden.

Bei der Aktion wird außerdem die Volume-Bitmap der freien Cluster korrigiert, und somit der Platz, an dem der Ordner früher lag, freigegeben.
Die Information, wo sich die Datei befindet, ist aber in irgendeiner Datei, die teilweise überschrieben ist, und an einer völlig anderen Stelle als im Index korrigiert wurde.

Jedes Datenrettungsprogramm wie GetDataBack kommt damit natürlich nicht klar und es wird Unsinn rauskopiert.

[Crabman1312]

Guten Morgen zusammen.

@MiamXD: Ich entnehme deiner Information, dass ich auf jeden Fall den DeeperSearch durchführen soll. Ich habe mir das auch vorgenommen, weil ich noch ein bisschen Hoffnung habe, dass es klappen kann. Die Partition finde ich ja schon im QuickSearch, habe allerdings Probleme bei der Wiederherstellung.
Dass der Durchlauf große Dateien überspringt habe ich auch gemerkt. Der QuickSearch sollte am Anfang etwa 100 Stunden dauern und brauchte nur 1/3 der Zeit. Ich hoffe, dass der DeeperSearch auch schneller geht. Kann ich ja mal messen und mitteilen.

@Ernst@at: Hmmm. Wenn ich das richtig verstanden habe, meinst du, dass ich mir mit chkdsk nicht nur die Informationen über die Dateiorte gelöscht habe, und daher mindestens die 11% der Daten nicht mehr wiederherstellen werden kann, sondern zusätzlich noch neue Daten (die Volume-Bitmap der freien Cluster) geschrieben habe, die auch mitten in meinen anderen Daten geschrieben worden sein können und dadurch möglicherweise sogar noch mehr als 11% der Daten korrumpiert habe. (hui, was für ein Satz...)

Was ist denn der Schluss daraus? Wenn ich jetzt weder mit testdisk, noch mit GetDataBack alle Daten recovern kann, ist mein ganzer Aufwand ja sinnlos, oder nicht?

[Ernst@at]

Es wäre schon mal hilfreich, wenn das Protokoll von chkdsk greifbar wäre.
Üblicherweise wird das im Win7 hier abgelegt:
Systemsteuerung -> Verwaltung -> Ereignisanzeige -> Windows-Protokolle -> Anwendung
Dann nach Wininit als Quelle suchen.
Ich weiß aber nicht, ob bei einem Abbruch da was eingetragen wird.

Soweit ich bisher durchgeblickt habe, betrifft es Ordner, welche über der 2TiB Grenze (ganz oder teilweise) abgelegt waren. Diese werden neu erstellt, und wenn in der $Bitmap dafür unterhalb der 2TiB Grenze dafür Platz gefunden wird, ist das unbedenklich.
Wird ein so korrigierter Ordner aber wieder über 2TiB recovert, dann wird er an falsche Stelle (2TiB zu tief) geschrieben, macht dort damit eine/mehrere andere Dateien kaputt und ist jetzt, nach Behebung des Adressierfehlers, wieder nicht vorhanden, da seine Daten nicht an dem Platz über 2TiB stehen. Dessen Dateien sind jetzt wieder verwaist.

Außerdem hat chkdsk die $Bitmap korrigiert, womit die Stellen der ursprünglichen Ordner freigegeben und die der neuen(teilweise aber gar nicht dort stehenden) belegt hat

Diese Erkenntnis betrifft einstweilen nur die Änderungen von chkdsk, was verwaiste Dateien betrifft.
Ob noch andere Zerstörungen angerichtet wurden, kann nur ein logfile zeigen.

[Crabman1312]

Ein Protokoll wurde leider nicht angelegt. Auch unter chkdsk habe ich nichts gefunden.

Als ich die Platte ausgebaut und an meinen anderen Rechner angeschlossen habe, hat chkdsk offensichtlich mal was gemacht, denn da habe ich ein Protokoll gefunden. Ich habe aber nicht mitbekommen, dass chkdsk ausgeführt wurde. Das bedeutet, dass chkdsk nicht sehr lange gearbeitet haben kann. Dessen Protokoll habe ich aber gefunden und mal angehangen.

Vielleicht gibt das ja noch einen Hinweis auf die Aktionen vom anderen Rechner.

testdisk ist inzwischen bei 86% des Deeper Searches und läuft und läuft und läuft. Hoffentlich wird er heute abend noch fertig.

[Ernst@at]

Das ist ein Protokoll eines normalen chkdsk-Laufes.
Gesucht wird eines mit Event-Id 1001 und Source/Quelle Wininit an dem Rechner/System, wo die Datenträgerüberprüfung vor dem Windows-Start gelaufen ist (Angabe lt. Post#1, 2. Absatz)

[Crabman1312]

Auf dem Rechner ist das Chkdskprotokoll leider nicht vorhanden.

testdisk ist zwar durchgelaufen, allerdings beim listen der files abgestürzt. Also nochmal laufen lassen...
Außerdem wurden die Partitions zwar erkannt, aber als "nicht recoverable" angezeigt.

Ich denke, ich werde mich von den Daten verabschieden müssen.

[Ernst@at]

Warte mit der Gedenkfeier und Kerzerlanzünden noch ein bisschen...

[MiamXD]

Das chkdsk Protokoll findest du in der Windows Ereignisanzeige, sobald Windows nach dem Durchlauf gestartet wurde.

[Ernst@at]

So weit waren wir auch schon, aber da scheint nichts eingetragen zu werden, wenn der Lauf abgebrochen und neugestartet wurde.

Selbst wenn es durchläuft und normal endet, ist die Größe der Logdatei limitiert und bei umfangreichen Änderungen nicht alles drin enthalten. MS-Schmuddellösung eben. Ein Undo dieser vermaledeiten Aktion ist schon überhaupt nicht vorgesehen.

Eine interne versteckte Systemdatei bootsqm.dat bzw bootex.log könnte eventuell noch erhellend sein, soferne sich sowas findet(bei entsprechender Explorer-Einstellung, versteckte und Systemdateien anzuzeigen)

[Crabman1312]

Eine bootsqm.dat habe ich nicht gefunden (versteckte Dateien sichtbar, geschütze Systemdateien eingeblendet). Wird wohl daran liegen, dass ich chkdsk abgebrochen habe.

Die bootex.log habe ich auch nicht gefunden, bin mir aber nicht sicher, ob ich an den richtigen Stellen gesucht habe.

testdisk ist inzwischen ein zweites Mal im Deeper Search durchgelaufen, hat wieder eine Partition mit den richtigen Parametern (NTFS, 3000GB, blocksize=512...) gefunden, sieht sich aber außer Stande, die Partition wiederherzustellen.
Mit testdisk kann man offensichtlich nur Partitionen retten, deren MBR noch vorhanden ist, bzw., dessen BackUp.

Inzwischen habe ich die relevanten Daten der Diplomarbeit von der Datenplatte neu berechnet. Das war zwar viel Arbeit, aber war einfacher, als weiter nach der Lösung zur Wiederherstellung der Platte zu suchen. Die anderen Daten, Images, Programme, Spiele, Videos usw. sind zwar verloren, aber ich sehe es als einen Neuanfang meiner Datensammlung. Ist zwar ärgerlich, aber nicht tragisch.

In Zukunft werde ich vorsichtiger sein, wenn ich RAID-Treiber (de-)installiere und die Datenplatte einfach abklemmen. Den Fehler mache ich sicherlich kein zweites Mal.

Für den Fall, dass ich wieder eine Platte schrotte, werde ich nicht mit irgendwelchen Tools versuchen die Platte auf die Schnelle zu retten und dabei die Situation verschlimmern, sondern erstmal in Ruhe nach dem Problem suchen. Uiuiui, da war ich aber auch ein Depp...

Ich fürchte, dass ich die Lektion einfach ein Mal auf die harte Tour lernen musste und jetzt mit erweiterter Erfahrung neu anfangen kann.

[Ernst@at]

Hast Du nur am System, oder auch auf der Partition, welche mit chkdsk behandelt wurde, gesucht?
Die Chance, dass viele der Dateien unbeschädigt sind und sich retten lassen, ist groß - zeigt meine dazu für einen anderen gleichartigen Fall beinahe fertiggstellte Analyse. Genaues kann ich erst in ein paar Tagen und nach Auslesen der Indexeinträge von deiner Disk sagen.

[Crabman1312]

Die kaputte Partition ist im Moment nicht formatiert. Da fehlt ja das GPT, weshalb die in Windows auch nicht sichtbar ist. Mit Datenrettungssoftware kann ich auch nicht nur die eine Datei finden, oder?

[Crabman1312]

Ich habe angefangen, die Platte neu zu beschreiben. Die alten Daten sind also verloren. Glücklicherweise war der Datenverlust nicht sehr tragisch, weil ich viele Daten woanders wiederfinden kann. Die DA-Daten sind inzwischen neu berechnet. Ich danke für Eure Hilfe!