Hi,
auch ich muß mich in die lange Liste der Partitionsverlust-Betroffenen einreihen.
An Ostern waren plötzlich alle logischen Partitionen weg. Mit Google fand ich hierher.
Mit Testdisk konnte ich 3 Partitionen wiederherstellen. Aber ausgerechnet die wichtigste mit den persönl. Daten bereitet größere Probleme (Murphy läßt grüssen)
Ich habe allerdings auch nur erst einen Versuch unternommen. Dank der vielen Posts kenne ich zwar die möglichen Optionen, bin mir aber nicht sicher in welcher Reihenfolge sie anzuwenden sind, um die Chanchen zur Datenrettung möglichst hoch zu halten.
Zu meinem System: Betroffen ist eine 160 GB Platte (Samsung SP1604N), die unter Win98SE benutzt wird.
Konfiguriert war sie in 3 Primäre und 4 Logische Partitionen:
1. (-) FAT16 versteckt (0,2 GB)
2. (C) FAT32 aktiv (5,8 GB) Win98-Systempart.
3. (-) FAT32 versteckt
Erweiterte Part. mit
5. (D) FAT32 (8,7 GB)
6. (E) FAT32 (8,9 GB)
7. (F) FAT32 (39 GB)
8. (G) FAT32 (78,1 GB)
Da das Board-BIOS große Platten >137GB unterstützt, VIA 4in1-Treiber installiert sind und Testdisk die korrekte Größe anzeigt, glaubte ich nicht vom BigLBA-Problem betroffen zu sein. Bin mir nun aber nicht mehr sicher. Später dazu mehr.
Was ich bis jetzt unternahm
Die Erst-Analyse mit Testdisk 5.7beta im DOS-Modus ohne Windows stimmte weitgehend mit meinen Notizen zur Partitionierung überein. Nur die erste logische Partition wurde nicht gelistet.
Disk 80 - CHS 19457 255 63 - 152627 MB
1..P..hid FAT16 >32M......0..1..1..-.........25..254..63
2..*...FAT32...................26..0..1..-.......790..254..63.....[SYSTEM1]
3..P..hid FAT32 LBA.....791..0..1..-.....1836..254..63
4..E..extended LBA.....1837..0..1..-.19456..254..63
....L..FAT 32 LBA........2998..1..1..-....4158..254..63.....[EXTRA]
....L..FAT 32 LBA........4159..1..1..-....9258..254..63.....[MMARC]
....L..FAT 32 LBA........9259..1..1..-..19456..254..63.....[MMWRK]
Auch zwei Suchläufe mit [Search] brachte diese nicht zum Vorschein. Also habe ich sie selbst per [Add] hinzugefügt.
[ Cylinders ] [ Heads ] [ Sectors ] [ Cylinders ] [ Heads ] [ Sectors ] [ Type ] [ Done ]
...1837..............1................1............2997...........254........... ...63.........0c.......[Enter]
Als Anhaltspunkt habe ich die von Testdisk angezeigte Lücke von Cyl. 1837 bis 2997 hergenommen. Diese ist zwar mit 8,9 GB etwas größer als das was in meinen Notizen stand. Aber da ich auch nicht die Größe der 3. Primären notiert hatte, gab ich der Analyse von Testdisk den Vorzug. [Write] bestätigt und Reboot.
Die Laufwerke E, F und G waren wieder ansprechbar. Nur bei D kam die Fehlermeldung "Ungültiger Medientyp …"
Den StatusQuo zeigen die Screenshots 1-4.
Mehr als ein Schuß mit Testdisk habe ich nicht gewagt, und erstmal alles was erreichbar ist gesichert. Während der Brennerei habe ich mir dann den Rest des Mega-Threads reingezogen (538 Posts sind ne Menge Soff) und einiges über die Möglichkeiten und Grenzen von Testdisk und der EnableBigLBA-Problematik erfahren. Nachdem alles gesichert war traute ich mich wieder Windows zu starten und Restorer2000 laufen zu lassen. Mit geschärften Blick fiel mir dann sogleich auf, daß die Platte nur mit 128 GB erkannt wurde. Im Logfenster scheint auch eine diesbezügliche Infomeldung zu stehen (Screenshot 5). Der Scan verlief relativ schnell, brachte aber nichts von meinen Daten auf D zum Vorschein. In einigen Volumes sind Dateien mit ungültigen Namen und Datum gelistet. Die Namen sehen nach Fragmenten aus einer Setupanweisung aus.
Ich hab Restorer2000 dann auch noch mal im abgesicherten Modus ausgeführt. Hier erkennt er die Größe korrekt und zeigt 149,1 GB. Der Scan dauerte auch erheblich länger (ca. 19 Stunden) und brachte das gleiche Ergebniss. Keine Daten
Aufgrund der Restorer2000-Anzeige im Windows-Normalmodus habe ich nun doch den Verdacht, daß BigLBA die Ursache des Schlamassel ist, obwohl erst ca. 90 GB auf der Platte sind. Aber der größte Teil liegt auf der letzten Partition. Allerdings verstehe ich noch nicht, warum es dann die erste logische Partition erwischt, wenn die Grenze überschritten wird und nicht die allererste am Anfang der Platte.
Meine brennenste Frage ist aber, in welcher Reihenfolge soll ich nun vorgehen?
Ich würde nach meinem jetzigen Kenntnisstand mit Testdisk [Delete] weitermachen und erneut [Search] ausführen, in der Hoffnung die Erkennungsvoraussetzungen zu verbessern. Ist es dabei angezeigt vorher die Partitionen mit fdisk zu löschen?
Falls Testdisk weiterhin D nicht findet, kann es bessere Ergebnisse bringen nochmal Datenrettungssoftware (Restorer2000 etc.) auf die Platte ohne Erweiterte Partition loszuschicken?
Jeder Hinweis hilft mir.
auch ich muß mich in die lange Liste der Partitionsverlust-Betroffenen einreihen.
An Ostern waren plötzlich alle logischen Partitionen weg. Mit Google fand ich hierher.
Mit Testdisk konnte ich 3 Partitionen wiederherstellen. Aber ausgerechnet die wichtigste mit den persönl. Daten bereitet größere Probleme (Murphy läßt grüssen)
Ich habe allerdings auch nur erst einen Versuch unternommen. Dank der vielen Posts kenne ich zwar die möglichen Optionen, bin mir aber nicht sicher in welcher Reihenfolge sie anzuwenden sind, um die Chanchen zur Datenrettung möglichst hoch zu halten.
Zu meinem System: Betroffen ist eine 160 GB Platte (Samsung SP1604N), die unter Win98SE benutzt wird.
Konfiguriert war sie in 3 Primäre und 4 Logische Partitionen:
1. (-) FAT16 versteckt (0,2 GB)
2. (C) FAT32 aktiv (5,8 GB) Win98-Systempart.
3. (-) FAT32 versteckt
Erweiterte Part. mit
5. (D) FAT32 (8,7 GB)
6. (E) FAT32 (8,9 GB)
7. (F) FAT32 (39 GB)
8. (G) FAT32 (78,1 GB)
Da das Board-BIOS große Platten >137GB unterstützt, VIA 4in1-Treiber installiert sind und Testdisk die korrekte Größe anzeigt, glaubte ich nicht vom BigLBA-Problem betroffen zu sein. Bin mir nun aber nicht mehr sicher. Später dazu mehr.
Was ich bis jetzt unternahm
Die Erst-Analyse mit Testdisk 5.7beta im DOS-Modus ohne Windows stimmte weitgehend mit meinen Notizen zur Partitionierung überein. Nur die erste logische Partition wurde nicht gelistet.
Disk 80 - CHS 19457 255 63 - 152627 MB
1..P..hid FAT16 >32M......0..1..1..-.........25..254..63
2..*...FAT32...................26..0..1..-.......790..254..63.....[SYSTEM1]
3..P..hid FAT32 LBA.....791..0..1..-.....1836..254..63
4..E..extended LBA.....1837..0..1..-.19456..254..63
....L..FAT 32 LBA........2998..1..1..-....4158..254..63.....[EXTRA]
....L..FAT 32 LBA........4159..1..1..-....9258..254..63.....[MMARC]
....L..FAT 32 LBA........9259..1..1..-..19456..254..63.....[MMWRK]
Auch zwei Suchläufe mit [Search] brachte diese nicht zum Vorschein. Also habe ich sie selbst per [Add] hinzugefügt.
[ Cylinders ] [ Heads ] [ Sectors ] [ Cylinders ] [ Heads ] [ Sectors ] [ Type ] [ Done ]
...1837..............1................1............2997...........254........... ...63.........0c.......[Enter]
Als Anhaltspunkt habe ich die von Testdisk angezeigte Lücke von Cyl. 1837 bis 2997 hergenommen. Diese ist zwar mit 8,9 GB etwas größer als das was in meinen Notizen stand. Aber da ich auch nicht die Größe der 3. Primären notiert hatte, gab ich der Analyse von Testdisk den Vorzug. [Write] bestätigt und Reboot.
Die Laufwerke E, F und G waren wieder ansprechbar. Nur bei D kam die Fehlermeldung "Ungültiger Medientyp …"
Den StatusQuo zeigen die Screenshots 1-4.
Mehr als ein Schuß mit Testdisk habe ich nicht gewagt, und erstmal alles was erreichbar ist gesichert. Während der Brennerei habe ich mir dann den Rest des Mega-Threads reingezogen (538 Posts sind ne Menge Soff) und einiges über die Möglichkeiten und Grenzen von Testdisk und der EnableBigLBA-Problematik erfahren. Nachdem alles gesichert war traute ich mich wieder Windows zu starten und Restorer2000 laufen zu lassen. Mit geschärften Blick fiel mir dann sogleich auf, daß die Platte nur mit 128 GB erkannt wurde. Im Logfenster scheint auch eine diesbezügliche Infomeldung zu stehen (Screenshot 5). Der Scan verlief relativ schnell, brachte aber nichts von meinen Daten auf D zum Vorschein. In einigen Volumes sind Dateien mit ungültigen Namen und Datum gelistet. Die Namen sehen nach Fragmenten aus einer Setupanweisung aus.
Ich hab Restorer2000 dann auch noch mal im abgesicherten Modus ausgeführt. Hier erkennt er die Größe korrekt und zeigt 149,1 GB. Der Scan dauerte auch erheblich länger (ca. 19 Stunden) und brachte das gleiche Ergebniss. Keine Daten
Aufgrund der Restorer2000-Anzeige im Windows-Normalmodus habe ich nun doch den Verdacht, daß BigLBA die Ursache des Schlamassel ist, obwohl erst ca. 90 GB auf der Platte sind. Aber der größte Teil liegt auf der letzten Partition. Allerdings verstehe ich noch nicht, warum es dann die erste logische Partition erwischt, wenn die Grenze überschritten wird und nicht die allererste am Anfang der Platte.
Meine brennenste Frage ist aber, in welcher Reihenfolge soll ich nun vorgehen?
Ich würde nach meinem jetzigen Kenntnisstand mit Testdisk [Delete] weitermachen und erneut [Search] ausführen, in der Hoffnung die Erkennungsvoraussetzungen zu verbessern. Ist es dabei angezeigt vorher die Partitionen mit fdisk zu löschen?
Falls Testdisk weiterhin D nicht findet, kann es bessere Ergebnisse bringen nochmal Datenrettungssoftware (Restorer2000 etc.) auf die Platte ohne Erweiterte Partition loszuschicken?
Jeder Hinweis hilft mir.
