Naja, da haben wir mal wieder die Arschkarte gezogen.
Die beiden rausgefallenen Platten sind die erste HDD des Arrays, auf der der MBR und die GPT-Information des Arrays stehen, und die andere HDD ist dessen Spiegelung, auf dem natürlich das gleiche steht.
Kriegt Win7 diese als Einzelplatten zu Gesicht, dann macht es in bester Absicht (weil die von MS alle zu blöd zum programmieren sind) hinten auf der Platte den GPT-Mirror des Arrays drauf, weil keiner hinten drauf ist (klar, denn der steht am Ende des Arrays, was ganz woanders liegt) und stört sich keineswegs dran, dass eine Partition eingetragen ist, die viel zu groß für die Einzelplatte ist...
Damit wurde schon mal auf diesen beiden Platten die RAID-Metainfo, wie der Array konfiguriert war und welcher Fehler zuletzt aufgetreten ist, überschrieben, und die GPT Info zeigt jetzt nicht mehr ans Ende des Arrays (was sich beheben lässt)
Wir müssen also die RAID-Info von den anderen beiden Platten holen, die im Moment noch nicht einzeln ansprechbar sind, weil sie noch im RAID-Array hängen.
Der eigentliche Auslöser für diesen Hoppala wird dieses verfluchte Windows.Verhalten gewesen sein. Wenn Du nach dem Update des BIOS erstmal hochgefahren bist, ohne die ICH10 Einstellung sofort auf RAID zu setzten, dan hat einfach das Win an den beiden Platten mit GPT die Metadaten des RAID-Controllers geschrottet; und das wars auch schon.
Das weitere Programm lautet also einfach:
- Sichern der MBR/GPT-Informationen;
- Umstellen ICH10R auf IDE, danach keinesfalls einem von Win gewünschtem Init dieser beiden Platten, die keinen MBR tragen, zustimmen !!! (sonst sind auch dort die Metadaten weg) bei der Gelegenheit kann man gleich auch den Gesundheitszustand aller vier Platten checken mit CrystalDiskInfo;
- Auslesen der RAID-Metadaten hinten auf den beiden anderen Platten
- Löschen der MBRs auf den Einzelplatten
- Rückstellen des ICH10R auf RAID, Neudefinition des RAID10 nach altem Konfigurationsschema
- Korrigieren der GPT-Information am Array
- Restore des MBR am Array
Die Anweisungen dazu schnitze ich Montag Abend/Nacht, wenn nichts dazwischenkommt.
_____
Bevor hier wieder einer was über onboard-Controller lästert:
Ich hab gerade ein etwas sehr durcheinandergekommenes RAID1 von einem Adaptec-Controller eines Serverboards am Seziertisch, um wenigstens eine wichtige Datenbank davon zu retten, die aus Versehen schon längere Zeit nicht gesichert wurde
Dort passierts halt nicht so häufig, ist aber genauso lustig...
Die beiden rausgefallenen Platten sind die erste HDD des Arrays, auf der der MBR und die GPT-Information des Arrays stehen, und die andere HDD ist dessen Spiegelung, auf dem natürlich das gleiche steht.
Kriegt Win7 diese als Einzelplatten zu Gesicht, dann macht es in bester Absicht (weil die von MS alle zu blöd zum programmieren sind) hinten auf der Platte den GPT-Mirror des Arrays drauf, weil keiner hinten drauf ist (klar, denn der steht am Ende des Arrays, was ganz woanders liegt) und stört sich keineswegs dran, dass eine Partition eingetragen ist, die viel zu groß für die Einzelplatte ist...
Damit wurde schon mal auf diesen beiden Platten die RAID-Metainfo, wie der Array konfiguriert war und welcher Fehler zuletzt aufgetreten ist, überschrieben, und die GPT Info zeigt jetzt nicht mehr ans Ende des Arrays (was sich beheben lässt)
Wir müssen also die RAID-Info von den anderen beiden Platten holen, die im Moment noch nicht einzeln ansprechbar sind, weil sie noch im RAID-Array hängen.
Der eigentliche Auslöser für diesen Hoppala wird dieses verfluchte Windows.Verhalten gewesen sein. Wenn Du nach dem Update des BIOS erstmal hochgefahren bist, ohne die ICH10 Einstellung sofort auf RAID zu setzten, dan hat einfach das Win an den beiden Platten mit GPT die Metadaten des RAID-Controllers geschrottet; und das wars auch schon.
Das weitere Programm lautet also einfach:
- Sichern der MBR/GPT-Informationen;
- Umstellen ICH10R auf IDE, danach keinesfalls einem von Win gewünschtem Init dieser beiden Platten, die keinen MBR tragen, zustimmen !!! (sonst sind auch dort die Metadaten weg) bei der Gelegenheit kann man gleich auch den Gesundheitszustand aller vier Platten checken mit CrystalDiskInfo;
- Auslesen der RAID-Metadaten hinten auf den beiden anderen Platten
- Löschen der MBRs auf den Einzelplatten
- Rückstellen des ICH10R auf RAID, Neudefinition des RAID10 nach altem Konfigurationsschema
- Korrigieren der GPT-Information am Array
- Restore des MBR am Array
Die Anweisungen dazu schnitze ich Montag Abend/Nacht, wenn nichts dazwischenkommt.

_____
Bevor hier wieder einer was über onboard-Controller lästert:
Ich hab gerade ein etwas sehr durcheinandergekommenes RAID1 von einem Adaptec-Controller eines Serverboards am Seziertisch, um wenigstens eine wichtige Datenbank davon zu retten, die aus Versehen schon längere Zeit nicht gesichert wurde

Dort passierts halt nicht so häufig, ist aber genauso lustig...