Raid0 wird nach Win7 Neuinstallation nicht mehr erkannt

[946021]

Hallo,

ich habe ein riesiges Problem und hoffe Ihr könnt mir weiterhelfen.

Und zwar habe ich 2x 2TB Western Digital HDDs an einem DeLOCK 89143 SATA-RAID-Controller (Jmicron 36xx Chipsatz) im Raid0 Verbund (striped, Blockgröße 128kb).

Dateisystem NTFS und als GPT konvertiert.
Eine große Partition mit 3726GB quasi.

Jetzt zum Problem: Nachdem ich Windows 7 neu installiert habe, wird meine Partition nicht mehr erkannt. Verwende den selben JMicron Raid Treiber, wie vorher auch. Kein Fehler im Gerätemanager.

Wenn ich die Datenträgerverwaltung starte findet er zwar den Datenträger (siehe initial.jpg). Wenn ich dann aber GPT auswähle und er den HDD Verbund initialisieren will friert mein Windows 7 nach 2-3 Minuten ein (auch im abgesicherten Modus).

Wenn ich beim Hochfahren des Rechners in die SATA-Controller Configuration gehe, wird mir aber kein Fehler angezeigt. Beide Festplatten sind da, der Verbundname "Raid 3.0" wird angezeigt. Alles in Ordnung.

Dasselbe Spiel in Windows 7 wenn ich den JMB36X Raid Configurer starte. Er findet den Raid Verbund, er findet beide Festplatten, kein Fehler nichts (siehe jmb36x.jpg).


Habt Ihr ne Ahnung woran das liegen kann? Hab ich mir möglicherweise irgendwie die GPT Partitionstabelle zerschossen?

Wie schaffe ich es die Partition wieder herzustellen? Oder zumindest drauf zugreifen zu können um die wichtigsten Daten absichern zu können?

Ich meine so lange der Verbund nicht gelöst worden ist müsste es doch möglich sein irgendwie wieder an die Daten ranzukommen, oder nicht?

Vielen Dank schon mal im voraus...

 

[Ernst@at]

Solange der RAID-0 Verbund nicht aufgelöst wurde und neu definiert, dürfte nicht einmal eine Änderung der Plattenreihenfolge eine Auswirkung auf die Erkennung der Daten haben.

Vielleicht hast Du was bei der Neuinstallation von Win7 vermurkst - ware die Platten dabei dran oder hast Du sie abgeklemmt?

Jedenfalls lässt sich in der derzeitigen Situation, wenn der RAID-Array "READY" status hat, mal nachsehen, was sich da vorne draufbefindet (oder auch nicht), ob die Partition(s) auffindbar sind (wieviele waren es denn?) oder ob anhand der GPT-Mirror-Informationen am Ende der Platte sich der Zugriff wiederherstellen lässt.

Jedenfalls solltest Du der Aufforderung, zu Initialisiern, erst mal NICHT nachkommen, weil sonst die alten Informationen für eine einfache Wiederherstellung endgültig weggeputzt werden.

Es wäre vielleicht auch nicht schlecht, wenn im ersten Bild das Fenster "RAID Informationen" so groß gemacht wird, dass man auch alles sehen kann, was da steht

 

[946021]

Das vollständige Fenster bei Raid Informationen ist jetzt im Anhang.

Die Platten waren dran als ich Windows 7 auf meiner OCZ 60GB SSD Festplatte installiert habe.
Das ist ja das komische, an den Platten vom Raid0 Verbund selber habe ich überhaupt nichts verändert.

Es war nur eine einzige Partition drauf über die vollen 3726GB.

Welche Software brauche ich jetzt um weitere Informationen zu sammeln?

 

[Ernst@at]

Befolge mal die Anweisungen dieses Posts.

 

[946021]

Das HxD hab ich jetzt installiert. Ich finde auch die beiden Festplatten aus dem Raid0 Verbund und kann mir den Hex Code anzeigen lassen.

Anbei im Anhang die letzten 4 Sektoren von den zwei Festplatten.

Kurz noch der Hinweis, ich lass gerade die Software "GetDataBack for NTFS" über den Raid0 Verbund laufen (Restzeit noch 11 Stunden) und er zeigt mir jetzt schon einiges an Dateien und Ordner an die auf dem Raid0 Verbund sind (getdatabackntfs.jpg).
Also dürften die Daten definitiv noch drauf sein.

Mehr als den Suchlauf von "GetDataBack for NTFS" lasse ich jetzt aber nicht machen.

 

[Ernst@at]

Natürlich sind die Daten noch drauf; dem Symptom nach wurde vorne mindestens der MBR überschrieben in Sektor 0 und die nachfolgende GPT (Partition Table)vielleicht, die auf den folgenden Sektoren ihren Platz hat.
Der MBR ist einfach zu rekonstruieren, und die GPT-Tabelle gibts am Ende der Platte nochmals. ob sonst noch was zerstört ist, kann man erst später feststellen.

Der GDB-Lauf wird 50% länger dauern als anfangs angezeigt und ist in dem Stadium eigentlich noch verfrüht, denn wenn die Partition nichts abbekommen hat, die erst ab Sektor 2048 beginnt, und nicht beschädigt wurde, braucht man das nicht.
Wenn Du willst, brich den ab; wenn Du ihn weiterlaufen lässt, speicher das Scanergebnis ab, dann brauchen diese 16-18 Stunden Scan nicht wiederholt werden.

Soweit ich sehe, hast du die letzten 4 Sektoren des RAID-Volumes in festplatte1.txt gepostet
ab Sektor 7813988348; der Inhalt der SystemSSD festplatte2 ist zum Problem nicht dienlich.

Am Ende von Festplatte1 ist aber auch nichts von einem GPT-Mirror zu finden, was verwunderlich erscheint. Naja.

Mach mal einen Auszug mit HxD von Sektor 2048 (Start: 0x100000 length: 0x200 )
und poste es als "RAID.2048.1.txt". Dort sollte der Start der Partition sein.

 

[946021]

Anbei die gewünschte Hex von Sektor 2048 von Festplatte 1

 

[Ernst@at]

Das sieht nicht nach einem Partitionbeginn aus.
Machen wir am Abend weiter...

 

[946021]

Alles klar, in jedem Fall schon mal danke für die raschen Antworten

Ergänzung (24. November 2010)

Sehr merkwürdig, ich habe grad nochmal zum Testen den Hexcode von Sektor 2048 von Festplatte 1 geholt und jetzt steht da was ganz anderes (RAID.2048.2.txt).

Vielleicht weil GTB noch lief und ich beim ersten mal keinen exklusiven Zugriff drauf hatte?

Aber was noch viel merkwürdiger ist: Wieso steht da was von ExFAT?

Ergänzung (24. November 2010)

Jetzt hab ich nach einem Neustart wieder nichts drin stehen wie in Screenshot RAID.2048.1.txt

 

[946021]

Ernst where are you? Assistance plz

 

[Ernst@at]

tut leid, war gestern verhindert und gerade erst aufgewacht (Gähn).

Der erste Auszug von der Platte zeigt einen leeren Sektor 2048, jetzt steht was drin.
Entweder hast Du beim ersten Mal dem HxD eine falsche Platte angegeben, oder jetzt.
Das in der Zwischenzeit etwas auf den Array geschrieben wurde, nehme ich ja nicht an.

Vor dem Aufruf von HxD sollte jedesmal die Datenträgerverwaltung geöffnet werden, und dann im HxD die um 1 höhere Nummer als physical/disk # geöffnet werden, beim Umstecken kann sich die Nummer ändern.
Wird der 3TB Array als Datenträger 0 angezeigt, dann eben physical disk 1 (vielleicht hast Du logical disk 1 genommen?)
Prüf das nochmal nach, was jetzt wirklich auf dem 4TB Array steht, zur Kontrolle siehst Du auch die max. Sektoranzahl in der HxD-Menüleiste, da sollte ein Wert von etwas weniger als 7814058336 Sektoren stehen.

 

[946021]

Ich vermute du hast recht. RAID.2048.2.txt wird wohl von der SSD HDD gewesen sein.

Screenshot RAID.2048.1.txt ist richtig. Es steht nichts im Sektor 2048. Grad nochmal überprüft

 

[Ernst@at]

Muss mir erst überlegen, wie wir die Suche am zweckmäßigsten weiterführen.
Bitte etwas Geduld, hier sind ein paar haarige Fälle in der Warteschleife

 

[946021]

Alles klaro...mein Schicksal liegt in deinen Händen

GDB hat gestern übrigens bei 100% gemeckert, dass es keine NTFS Partition finden könne und deshalb die Partition nicht wiederherstellen kann.

 

[Ernst@at]

Das ist allerdings sehr bedenklich - war das Array gar ein encrypted Volume?

 

[946021]

Nein war nichts verschlüsselt

Ergänzung (24. November 2010)

hm, jetzt finde ich auf einmal wieder Sektor 2048 wie in Bild RAID.2048.2.txt

Und es ist ganz klar das Raid0 Array mit 7813988352 Sektoren.

Also der Erste Sektor indem was drinsteht ist 2048 -> RAID.2048.2.txt
Und der letzte Sektor indem was drinsteht ist 7813986303 -> RAID.7813986303.2.txt

Falls das was hilft...

 

[Ernst@at]

Ja, das am Ende hilft ungemein - ich stell das gleich mal im Klartext hier dazu.

Analyzing: \\Pc10\shareddocs\946021 RAID0\RAID.7813986303.2.txt

===== NTFS INFORMATION ===== at LBA=7813986303
3A37FEFFFFE 55AA             Boot signature='55AA'... valid
3A37FEFFE00 EB5290           jump around... OK
3A37FEFFE03 4E54465320202020 NTFS ID... OK
3A37FEFFE0B 0002             Bytes per sector: 512
3A37FEFFE0D 08               Sectors per cluster: 8 ==> Clustersize=4K
3A37FEFFE0E 0000             reserved sectors: 0
3A37FEFFE10 000000           always zero...OK
3A37FEFFE13 0000             not used...OK
3A37FEFFE15 F8               <Media descriptor>
3A37FEFFE16 0000             always zero...OK
3A37FEFFE18 3F00             Sectors per track: 63
3A37FEFFE1A FF00             # heads: 255
3A37FEFFE1C 00080400         # hidden sectors: 264192
3A37FEFFE20 00000000         <not used by NTFS>
3A37FEFFE24 80008000         <not used by NTFS>
3A37FEFFE28 FFEFBBD101000000 Total Sectors: 7813722111
.                            ==> Size:3815294MB 3725.87GB
.                            ==> NTFS Origin at sector: 264192 ==> Sector placement: OK
3A37FEFFE30 00000C0000000000 Cluster# of $MFT: 786432
.                            ==> $MFT at sector: 6555648
3A37FEFFE38 0200000000000000 Cluster# of $MFTmirr: 2
.                            ==> $MFTmirr at sector: 264208
3A37FEFFE40 F6000000         Clusters/File Record Segment: 246
3A37FEFFE44 01000000         Clusters/Index Block: 1
3A37FEFFE48 F03457C86657C824 Volume Serial #
3A37FEFFE50 00000000         checksum

Somit scheint das da vorne die reserved Partition von 100MB zu sein, die NTFS-Partition beginnt auf Sektor 264192.
Sieh dort mal nach, da müsste exakt das gleiche stehen wie am Ende im NTFS-Bootrec-Mirror, den Du da hinten gefunden hast

 

[946021]

264192 ist leer, aber ab 264193 bis 264200 steht einiges -> 264193-264200.txt

 

[Ernst@at]

Nun - das wäre erklärbar, wenn Du nach der Beschreibung im Erstpost den uninitialisierten (wodurch auch immer das zustandegekommen ist) Datenträger initialisiert und wieder im Zuge der Neuinstallation die Partition in maximaler Größe angelegt hast, dabei wird der erste Block (der NTFS-Bootsektor) gelöscht. Dahinter (ab 264193) steht ja das, was man eigentlich am Beginn einer Partition normalerweise vorfindet.
Die Frage ist nur, wie wir das wieder hinkriegen - denn am Ende des Arrays ist keine Spur mehr vom Mirror der GPT-Partitiontabelle, die auch vorne auf Sektor 1-33 vorhanden sein sollte.

Ich steh etwas neben mir, weil ich mich jetzt einige Monate nicht mit der Materie befasst habe.
Kann mir im Moment nicht erklären, wie bei einem 4TB Datenträger hinten und vorne die GPT-Info selektiv verschwindet.

Lass mich mal eine Nacht drüber schlafen...

 

[946021]

Soll ja auch ne Herausforderung an Dich sein

Gibts denn vielleicht ne andere Möglichkeit an die Daten ranzukommen, ohne die GPT Partitionstabelle wiederherstellen zu müssen?

Oder was wäre z.B. damit:

http://www.rodsbooks.com/gdisk/repairing.html

Oder TestDisk? -> EFI GPT und dann ne Analyse vielleicht?