RAID10 an Intel ICH10R durch ES-Tool aufgelöst
- Ersteller kolaj
- Erstellt am
Nun, das lustige ESTool zerstört offensichtlich auf den Einzelplatten die letzen 16384 (=2^14) Sektoren und hat damit am Array die letzten 19664 Sektoren (etwa 10MB) überschrieben.
Darum werden wir uns später kümmern.
Zuerst reparieren wir die Partition, ich stell das in den Anweisungen unter Punkt 4.2 zusammen - damit setzt Du fort.
Der Bootrec vom Beginn der Partition wird an die überschriebene Mirror-Position am Ende übertragen, damit wird sie für die Filesystem-Überprüfung als unbeschädigt betrachtet.
Darum werden wir uns später kümmern.
Zuerst reparieren wir die Partition, ich stell das in den Anweisungen unter Punkt 4.2 zusammen - damit setzt Du fort.
Der Bootrec vom Beginn der Partition wird an die überschriebene Mirror-Position am Ende übertragen, damit wird sie für die Filesystem-Überprüfung als unbeschädigt betrachtet.
Code:
[FONT="Lucida Console"][SIZE="3"]Analyzing: \\Pc10\shareddocs\kolaj RAID10\P2Hdr.txt
===== NTFS INFORMATION ===== at LBA=126240768
00F0C9001FE 55AA Boot signature='55AA'... valid
00F0C900000 EB5290 jump around... OK
00F0C900003 4E54465320202020 NTFS ID... OK
00F0C90000B 0002 Bytes per sector: 512
00F0C90000D 08 Sectors per cluster: 8 ==> Clustersize=4K
00F0C90000E 0000 reserved sectors: 0
00F0C900010 000000 always zero...OK
00F0C900013 0000 not used...OK
00F0C900015 F8 <Media descriptor>
00F0C900016 0000 always zero...OK
00F0C900018 3F00 Sectors per track: 63
00F0C90001A FF00 # heads: 255
00F0C90001C 00488607 # hidden sectors: 126240768
00F0C900020 00000000 <not used by NTFS>
00F0C900024 80008000 <not used by NTFS>
00F0C900028 FF5F5AE100000000 Total Sectors: 3780796415
. ==> Size:1846092MB 1802.82GB
. ==> NTFS Mirror at sector: 3907037183 ==> Sector placement: OK
00F0C900030 00000C0000000000 Cluster# of $MFT: 786432
. ==> $MFT at sector: 132532224
00F0C900038 0200000000000000 Cluster# of $MFTmirr: 2
. ==> $MFTmirr at sector: 126240784
00F0C900040 F6000000 Clusters/File Record Segment: 246
00F0C900044 01000000 Clusters/Index Block: 1
00F0C900048 406E0E3EAA0E3EEC Volume Serial #
00F0C900050 00000000 checksum [/SIZE][/FONT]
Zuletzt bearbeitet:
Die letzten Schritte haben einwandfrei geklappt! Das Booten vom Array sowie der Zugriff auf die Daten ist wieder möglich! Ich bin Dir unbeschreiblich dankbar!
Werde jetzt mit HD Sentinel die erste Platte beobachten.
Alles klar, ich warte auf weitere Instruktionen
Werde jetzt mit HD Sentinel die erste Platte beobachten.
Alles klar, ich warte auf weitere Instruktionen
So, hier ist die
Viel Spass! Die gefundenen Dateien sind leider zumindestens teilweise zerstört und haben an diesen Stellen das 1234-Syndrom
Wenn du von Hier das Zip entpackst ist ein Ordner nfi mit einem Programm nfi.exe drinnen. Das Kopierst Du in das Arbeitsverzeichnis Deiner Eingabeaufforderung.
unter Annahme, die Datenpartition sei Laufwerk D:
Mit dem Befehl nfi d:39070371753780796407
erhältst Du
39070175203780776743
ist.
unter Annahme, die Datenpartition sei Laufwerk D:
Mit dem Befehl nfi d:
erhältst Du
- entweder die Meldung, dass keine Datei gefunden wurde,
dann verminderst du die Zahl um 8 zB. 3780796407-8=3780796399 bis
- oder es zeigt den Dateinamen und eine Clusterliste, die er belegt, zB:
logical sectors 42831288-42831303
logical sectors 56842704-56842711
logical sectors 88128552-88128559
logical sectors 89953136-89953143
logical sectors 3787020784-3780796407
logical sectors 26764384-26764391
Daraus musst Du jetzt die Zeile mit der übereinstimmenden Endnummer(fett) finden,
und machst mit dem Beginnwert-1, hier im Beispiel mit 3787020783 weiter, bis
ist.
Viel Spass! Die gefundenen Dateien sind leider zumindestens teilweise zerstört und haben an diesen Stellen das 1234-Syndrom
Zuletzt bearbeitet:
(es waren absolute statt relative Sektornummern)
So, habe jetzt die Sektoren 3907037175 bis 3907017519 untersuchen lassen und es kam immer die Meldung
***Logical sector xxxxxxxxxx (0xxxxxxxxx) on drive D is not in any file.
Bedeutet das, dass ich aufatmen kann und keinerlei Datei beschädigt ist, da der Schreibtest des ES-Tools nur in Sektoren geschrieben hat, die keine Nutzdaten enthielten?
***Logical sector xxxxxxxxxx (0xxxxxxxxx) on drive D is not in any file.
Bedeutet das, dass ich aufatmen kann und keinerlei Datei beschädigt ist, da der Schreibtest des ES-Tools nur in Sektoren geschrieben hat, die keine Nutzdaten enthielten?
Richtig, Glückwunsch zur 100%igen Rückgewinnung der Daten. Der Array ist wieder im Ursprungszustand.
Der Bereich am Ende der Partition wird üblicherweise erst bei ~87% Befüllung verwendet, wenn nicht durch Defrag(zB zonenbasiertes) Dateien dorthin verschoben werden.
Du kannst auch die Gegenprobe machen: gib bei nfi den kompletten Pfad einer Datei ein, welche du zuletzt auf dieser Partition gespeichert hast, das zeigt Dir, wo die physisch drauf abgelegt wurde.
z.B. >nfi "C:\Dokumente und Einstellungen\All Users\Dokumente\kolaj RAID10\start1234.zip"
...und ob der Euphorie nicht auf HD Sentinel vergessen!
Der Bereich am Ende der Partition wird üblicherweise erst bei ~87% Befüllung verwendet, wenn nicht durch Defrag(zB zonenbasiertes) Dateien dorthin verschoben werden.
Du kannst auch die Gegenprobe machen: gib bei nfi den kompletten Pfad einer Datei ein, welche du zuletzt auf dieser Partition gespeichert hast, das zeigt Dir, wo die physisch drauf abgelegt wurde.
z.B. >nfi "C:\Dokumente und Einstellungen\All Users\Dokumente\kolaj RAID10\start1234.zip"
...und ob der Euphorie nicht auf HD Sentinel vergessen!
Zuletzt bearbeitet:
Super, nochmals vielen Dank!
Dann schein ich ja echt Glück gehabt zu haben, denn die Partition ist auf jeden Fall zu mehr als ~87% befüllt - nämlich zu etwa 99% (nur noch ca. 5 GiB von 1,75 TiB frei)
.
Ach eine Frage hab ich noch: Sollte ich Partition C ebenfalls auf Datenverlust überprüfen und falls ja, welche Sektoren sind dort zu untersuchen?
Jo, HD Sentinel wird genutzt!
Dann schein ich ja echt Glück gehabt zu haben, denn die Partition ist auf jeden Fall zu mehr als ~87% befüllt - nämlich zu etwa 99% (nur noch ca. 5 GiB von 1,75 TiB frei)
.Ach eine Frage hab ich noch: Sollte ich Partition C ebenfalls auf Datenverlust überprüfen und falls ja, welche Sektoren sind dort zu untersuchen?
Jo, HD Sentinel wird genutzt!
Zuletzt bearbeitet:
Halt! Stopp! ich hab da was falsch berechnet! 99% voll ließ mich stutzig werden
Die 1. Partition hast Du ja schon mit chkdsk geprüft, da kann sonst nichts kaputt sein.
Mein Fehler zur Geisterstunde - Die Sektornummer zum prüfen der 2.Partition muss relativ zum Beginn sein(wenn die größer als die Partition ist, kratzt das nfi nicht und sagt bloss - nichts gefunden)
d.h. nfi d: 0 zeigt $Boot, den NTFS-Bootsektor am Partitionbeginn, Sektor 0-7.
Die Partition beginnt auf 126240768 und endet auf 3907037183, letzter Datencluster ist 8 Sektoren davor auf 3907037175. Abzüglich Partitionbeginn ist das relativer Sektor 3780796407
Abzüglich 19664 zerstörter Sektoren gibt das relativen Sektor 3780776743
Innerhalb dieser Grenzen musst Du die Suche leider nochmal durchführen.
Ich hab das Post #30 dahingehend ausgebessert.
Die Gegenprobe kannst Du mit HxD machen, Zieh die Datei aus dem Explorer in HxD-Fenster und suche nach 1234123412341234 hex, Du wirst das innerhalb der Datei finden
Die 1. Partition hast Du ja schon mit chkdsk geprüft, da kann sonst nichts kaputt sein.
Mein Fehler zur Geisterstunde - Die Sektornummer zum prüfen der 2.Partition muss relativ zum Beginn sein(wenn die größer als die Partition ist, kratzt das nfi nicht und sagt bloss - nichts gefunden)
d.h. nfi d: 0 zeigt $Boot, den NTFS-Bootsektor am Partitionbeginn, Sektor 0-7.
Die Partition beginnt auf 126240768 und endet auf 3907037183, letzter Datencluster ist 8 Sektoren davor auf 3907037175. Abzüglich Partitionbeginn ist das relativer Sektor 3780796407
Abzüglich 19664 zerstörter Sektoren gibt das relativen Sektor 3780776743
Innerhalb dieser Grenzen musst Du die Suche leider nochmal durchführen.
Ich hab das Post #30 dahingehend ausgebessert.
Die Gegenprobe kannst Du mit HxD machen, Zieh die Datei aus dem Explorer in HxD-Fenster und suche nach 1234123412341234 hex, Du wirst das innerhalb der Datei finden
Zuletzt bearbeitet:
!Ähnliche Themen
