Intel RST - nach Umkonfiguration lässt sich RAID 1 nicht mehr in Windows 7 einbinden - Datenverlust

emulbetsup

Vice Admiral Special
Mitglied seit
09.02.2006
Beiträge
523
Renomée
24
Mein Vater liegt nach der zweiten schweren OP innerhalb von einer Woche weiterhin in der Klinik. Deshalb habe ich versprochen mich um sein inkonsistentes RAID zu kümmern, auf dem leider wichtige Daten liegen von denen es leider auch kein weiteres Back Up gibt.

Mein Vater betreibt seit einigen Jahren ein RAID System (onboard Intel-Lösung eines I7 Nehalem Chipset) mit zwei WDC Caviar Green 640 GByte HDDs. Im Zuge des Neueinbaus einer Samsung SSD hat er das RAID umkonfiguriert und hat jetzt als Resultat leider kein Zugriff mehr auf seine Daten, die vorher als RAID 1 organisiert waren. Vor dem Einbau der SSD war die Situation wie folgt:

HDD_Papa_01.jpg

Folgende Änderungen wurden dann vorgenommen:

1. Einbau der Samsung SSD und Migration der OS Partition (vorher RAID 0) mit der Samsung Magician Software. Daraus resultierte eine System-Partition mit den vollen 500 GByte (+ die obligatorische 100 MByte systemreservierte Partition) auf der neuen SSD. Von dieser neuen Partition konnte/kann ohne Probleme gebootet werden. Danach waren sowohl die alte Systempartition (RAID 0) und die Datenpartition (RAID 1) unter teils anderen Laufwerksbuchstaben ansprechbar

2. Verkleinerung der neuen Betriebssystempartition (SSD) auf 200 GByte und Einrichtung einer neuen Partition auf der SSD mit 300 GByte (mit der Windows Datenträgerverwaltung)

3. Löschen der alten Betriebssystempartition (RAID 0) mit der Intel RST Software. Ziel war es den zusätzlichen Speicherplatz der alten Systempartition der als RAID 1 organisierten Datenpartition hinzuzufügen.

4. Deshalb wurde mit der Intel RST Software der freie Speicherplatz dem RAID 1 hinzugefügt. Die Anzeigen des Tools waren dabei immer korrekt (vorher RAID 1 mit 500 GByte - danach RAID 1 mit 596 GByte). Allerdings fehlte danach die Datenpartition im Explorer und die Windows Datenträgerverwaltung hat wohl folgendes angezeigt:

(Hier komme ich mit den Darstellungen meines Vaters via E-Mail nicht mehr ganz mit, deshalb diese Infos als Zitate)

Zu Datenträger 1 (oder 0): Rechteck mit / 99 Mb / Hinweistext „Fehler“ + Rechteck mit ca. 499 GB / Hinweistext „Fehler“ + Rechteck mit ~ 92 GB / Hinweistext „Fehler“ KEINE LAUFWERKSBUCHSTABEN

Weiter unten (Datenträger ?) mit einem roten * oder X gekennzeichnet: Rechteck mit 192 GB (das war ja Raid 0) / Hinweistext: „Fehlend“; der Text könnten auch ganz vorne gestanden haben, nicht innerhalb des Rechtecks

Folgende Rechtecke waren mit einem Balken über dem Rechteck gleicher Farbe gekennzeichnet (sollte irgendwas mit „verbundenem Volumen / dynamisches Volumen gewesen sein, genau weiß ich es nicht mehr):

99 + 499 + 192 (die 92 waren nicht dabei, so meine ich)

Hier scheint schon einiges durcheinander gekommen zu sein! Offensichtlich wurden die zwei physischen Platten des RAID-Verbundes auch als zwei physische Platten in der Windows DT-Verwaltung angezeigt!

Danach hat mein Vater die folgenden Schritte unternommen:

- Habe dann jeweils versucht die einzelnen Rechtecke zu reaktivieren, was nichts bewirkte und habe auch den Rechner neu gestartet. Alles ohne Wirkung.

- Da die 192 GB als <fehlend> gekennzeichnet waren, habe ich diese einfach gelöscht über das Kontextmenü (Volumen löschen).

- Das hatte die Wirkung, dass die 192 GB nun weg waren und die Anzeige wie oben für den Datenträger 0 vorlag (aktueller-Zustand), d.h. die einzelnen Rechtecke wurden zusammengefasst.

- Jetzt habe ich im Intel RST die Überprüfung/Initialisierung (Neuaufbau gestartet). Das ging vielleicht 2-3 h, lief aber ohne Probleme durch.

- Die Anzeige im I-RST hat sich nicht verändert und alles blieb wie zuvor Normal (wie oben angezeigt).

Hier sind noch einige Screenshots vom Ist-Zustand und den angebotenen Optionen.

HDD_Papa_03.jpg HDD_Papa_04.jpg HDD_Papa_05.jpg HDD_Papa_06.jpg

Im BIOS des RAID-Controllers werden folgende Infos ausgegeben

A.) Menü:

1. Create Raid Volume

2. Delete Raid Volume

3. Reset Disk to NON-Raid

4. Recovery Volume Options

________________________________________________________________________________________

B.) Anzeige (Info)

ID Name Level Strip Size Status Bootable

0 Roman_Raid1 Raid1(Mirror) N/A 596,2GB Normal Yes

________________________________________________________________________________________

Physical Disks:

Port Size Type/Status (Vol ID)

0 WDC WD….WD-WCAV51469573 596,1 GB Menber Disk (0)

1 WDC WD….WD-WCAV51500050 596,1 GB Menber Disk (0)

3 Samsung SSD 850… 465,7 GB Non-Raid Disk

________________________________________________________________________________________

Meine Gedanken dazu:
Falls die Darstellungen meines Vaters von der Windows DTV (erstes Quote) richtig sind, ist schon davor einiges durcheinander geraten. Sonst hätte Windows hier keine zwei physischen Platten anzeigen dürfen. In Folge der weiteren Rettungsversuche mit zwei unterschiedlichen Tools (Windows DTV und Intel RST) sind wahrscheinlich auch die Partitionierungsdaten vollständig hinüber.

Jetzt meine Fragen:
1. Gibt es eine einfache Lösung für das Problem?

2. Würden Option "3. Reset Disk to NON-Raid" oder "4. Recovery Volume Options" im BIOS irgendetwas in die richtige Richtung bewegen?

3. Sind nach der Neuinitialisierung (zweites Quote und der einzige Vorgang der tatsächlich nennenswert Zeit gekostet hat) noch die eigentlichen Daten des RAID 1 überhaupt noch vorhanden oder werden die vom Intel RST bei diesem Vorgang routinemäßig überschrieben?

4. Welche Chancen haben wir noch an die Daten zu kommen? Spontan denke ich an die neuste Version von Ontrack Easy Recovery, das mir bei einem ähnlich gelagerten Problem (allerding ohne RAID) schonmal die komplette Partitionierung gerettet hat. Die Strip-Size wird zwar nicht mehr ausgegeben, aber afair hat er diese Information irgendwo aufgeschrieben.

5. Wurde durch irgendeine der durchgeführten Aktionen der physikalische Speicherort der Daten verändert? Das wäre ja vor allem dann wichtig, wenn man die Partitionierungsdaten mit Hilfe der Startsektoren wieder herstellen müsste.

6. Durch das RAID 1 sind/waren ja die Daten auf beiden Platten vollständig vorhanden. Wie werden die Partitionierungsdaten allgemein bei einem RAID 1 geschrieben? Verhält sich jede Einzelplatte in einem anderen Rechner wie eine Non-Raid-Disk?

Vielen lieben Dank für eure Antworten und viele Grüße,

Zwieback

PS: Werde den Thread wahrscheinlich auch noch bei CB einstellen, also bitte nicht wundern.
 
Zuletzt bearbeitet:
Das kannst Du alles vergessen, spätestens nach der Änderung der Größe des RAID 1 war das Filesystem im Eimer, denn dessen Kennung steht am Anfang der Partition und dieser liegt nun weiter vorne. Wenn, dann kann man die Partitionen mit der Windows Datenträgerverwaltung immer nur nach rechts (also hinten) erweitern, zum Verschieben nach links braucht man immer 3rd Party Tools und die weisen einen auch zurecht darauf hin vorher ein Backup anzulegen. Die wichtigsten Daten hätte er vorher zumindest von RAID 1 auf die freigemachte Partition der SSD kopieren sollen, wenn er schon nicht nur an den Partitionen schon auch gleich noch am RAID rumfummeln muss.

Da es um das RAID 1 geht, kannst Du mal versuchen was die Recovery Tools wie Testdisk oder dessen kommerziellen Alternativen wie GetDataBack, Zero Assumption Recovery (das kann auch mit RAIDs umgehen), etc. so finden und retten können, kopieren aber die Daten auf eine andere Platte und nicht auf das RAID.

Erkläre dann mal Deinem Vater auch, dass RAIDs keine Backups ersetzen! Zu den dort genannten Gründen kommt noch die Fragilität der RAIDs, die nicht nur bei Hardwarefehlern des RAID Controllers Probleme macht, sondern eben auch wenn der User am RAID oder den Partitionen darauf rumfummelt.
 
Danke für deine Einschätzung. Daten ohne Dateistruktur zu retten wäre wirklich nur der allerletzte Notnagel, da sicher auch zahlreiche Files bis zur unkenntlichkeit fragmentiert sind. Das ein RAID 1 keine zuverlässige Datensicherung ist kam auch schön des Öfteren zur Sprache. Das wußte sogar unser Weihnachtmann, der meinem Papa vor nicht allzu langer Zeit eine externe HDD für genau diesen Zweck unter dem Baum legte. Inklusive entsprechender Software für inkrementelle Back-Ups...

Aber nun zum Stand der Dinge:

Akutell experimentiere ich gerade mit einem analogen System (HP XW 4600 - Intel X38 - 2x Samsung HD501LJ)

Habe beide Platten mit dem Samsung ESTool Low Level formatiert und zusätzlich den ersten und den letzten Sektor beider Platten mit einem HEX-Editor überschrieben (beide somit unter dem Gesichtspunkt wieder jungfräulich). Zusätzlich habe ich eine weitere Installation auf einer dritten Platte installiert, um dann mit dieser Installation die tiefgreifenden Veränderungen nach dem Clonen der Partition zu tätigen und deren Ergebnis dann mit dem HEX-Editor nachvollziehen zu können

Wenn ich das richtig verstanden habe, sind bei MBR-Datenträger sämtliche Partitionierungsdaten (also die Einteilung in die 4 primären (bzw. die drei Primären und der Verweis auf eine Erweiterte) im ersten Sektor der HDD gespeichert.

Von der ganzen Aktion erhoffe ich mir Folgendes. Sollte ich hier Unsinn erzählen bitte ich um eure Richtigstellung, da ich mich hier fernab von jedweder persönlicher Expertise bewege. Learning by doing sozusagen...

1. Durchtesten der verschiedenen Tools ohne die eigentlichen Daten zusätzlich durch unnütze Rettungsversuche zu gefährden.

2. Finden des ersten LBAs des alten RAID 1
Partitionen werden ja afair nach aufsteigender LBA beschrieben. Das heißt, dass bei fabrikneuen Platten, die nie vollständig beschrieben wurden, zwischen zwei Partitionen zahlreiche Sektoren mit "00" zu finden sein sollten. Mglw. kann ich auch beim Testdurchlauf (dessen LBAs ich natürlich kenne ;)) charakteristische Eintragungen finden und dann entsprechend bei den beiden zerschossenen Platten identifizieren.

=> AFAIR kann Easy Recovery Professional unter Angabe des (ungefähren?) Start LBAs, dem ursprünglichen Dateisystem und der Clustergröße die Dateien und deren Struktur vollständig wieder auslesen. Das wäre dann die eleganteste Variante. Das wird allerdings sicher nur dann funktionieren, wenn am tatsächlichen Partitionsanfang nichts verändert wurde und lediglich die Partitionstabelle im ersten Sektor entsprechend angepasst wurde.

3. Manuelles Wiederherstellen der Partitionsinformationen
Ziemlich verrückte Idee, aber sie lässt mich nicht ganz los. Sollte ich an die genauen Partitionsdaten kommen, aber kein Tool das oben angerissene Verfahren beherrschen, könnte man versuchen den MBR händisch auf die alten Werte zu editieren. Sind theoretisch nur 63 HEX-Werte, also schwer aber vielleicht nicht ganz aussichtslos.

So, das sind meine Überlegungen zum aktuellen Stand. Was haltet ihr davon?

Noch was anderes: Wie verhält sich denn eine einzelne Platte (Partition) eines RAID 1 Verbundes? Ist die an einem anderen Rechner ohne die zweite Platte und ohne entsprechendem Controller in etwa so ansprechbar, wie wenn es keine zweite Platte (Partition) gegeben hätte?

Viele Grüße,

Zwieback
 
Zuletzt bearbeitet:
Im Prinzip ganz vernünftige Ansätze, google mal ob und wenn ja welche Markierungen es am Anfang einer Partition gibt. Die originale Partitionierung wiederherstellen zu können, wäre sicher ein Fortschritt. Da ja auf den Platten sowohl ein RAID 0 als auch ein RAID 1 realisiert war, dürfte die zerstückelten Informationen vom RAID 0 die Rettungsprogramm verwirren. Ein Hinweis auf den Anfang der Partition könnte die Position der $MFT sein und beachte, dass die RAIDs am Anfang Metadaten haben, ich meine die ersten 1024k. Wie das konkret aussieht wenn man nun zwei RAIDs auf einer Platte erstellt, kann ich aber nicht sagen. Macht man die RAIDs über die ganze Platte so steht der eigentlich MBR eben nicht mehr auf LBA0 der Platte, sonern eben hinter den Metadaten.

Wegen der Metadaten vor den eigentlichen Daten ist es auch nomalerweise nicht möglich eine Platte aus einem RAID 1 einfach als einzelnes Laufwerk zu nutzen, da dann die Daten am Anfang der Platte, die ja die Metadaten des RAID und nicht z.B. den MBR enhalten, falsch interpretiert werden. Man müsste also wenigstens einen neuen MBR konstruieren der entsprechend verschobene Partitionierungsinformationen enthält, was bei GPT dann noch einmal kompliziertet wird.
 
Also, nachdem ich das Problem so gut wie es ging nachgestellt habe, sind wir zu einer Lösung gekommen. Exakt lies sich das Problem leider nicht nachstellen, da bei der Probeinstallation die verhängnisvolle Option (bestehendes RAID 1 um den freigewordenen Speicherplatz erweitern) nicht angeboten wurde. Letztendlich habe ich dann im BIOS des RAID-Controllers beide RAIDs manuell gelöscht und anschließend ein neues RAID 1 über den gesamten Speicherplatz neu erstellt. Die "Lösung" hat dann aber bei beiden Varianten funktioniert:

Folgendes konnte ich über MBR-organisierte Laufwerke/RAID-Verbünde herausfinden:

RAID 0
Sektoren des RAID Verbundes 419430400 - 200 GByte

Inhalte
Sektor 0: Partitionstabelle
Sektor 1 bis 2047: gähnende Leere
Sektor 2048 bis 206847: Partition 01 - Win7 System reserviert - 100 MByte (beginnt und endet mit "ëR.NTFS" zu Beginn des jeweils ersten und letzten Sektors)
Sektor 206848 bis 419428351: Partition 02 - Win7 Installation - 199,9 GByte (beginnt und endet mit "ëR.NTFS" zu Beginn des jeweils ersten und letzten Sektors)
Sektor 419428352 bis 419430400: gähnende Leere

RAID 1
Sektoren des RAID Verbundes 767047680 - 365,76 GByte

Inhalte
Sektor 0: Partitionstabelle
Sektor 1 bis 2047: gähnende Leere
Sektor 2048 bis 767043583: Partition 01 - Datenpartition - 365,76 GByte (beginnt und endet mit "ëR.NTFS" zu Beginn des jeweils ersten und letzten Sektors)
Sektor 767043583 bis 767047680 gähnende Leere

Ohne RAID-Controller ausgelesen hatte eine einzelne HDD insgesamt 976773168 Sektoren.

"Leider" war es dann nicht mehr nötig tiefer in die Materie einzutauchen, da "Kroll Ontrack EasyRecovery 11 Home" die verlorenen Partitionsdaten auslesen konnte und sämtliche Daten inkl. Dateipfade wieder herstellen konnte. Mit der kostenlosen Variante Testdisk konnten die betreffenden Partitionen dagegen nicht wieder hergestellt werden.

Nochmals vielen Dank für eure Hilfe!

Zwieback
 
Zurück
Oben Unten