Intel Raid5 Wiederherstellen (Ausfall von zwei Festplatten)

Also, die Platte2 hat ähnliche Daten wie die Platte1 in den ersten Sektoren. Ich muss auch die Platten vorm Start des Windows abgezogen haben, ansonsten hängt sich dieses beim Booten auf. Kann die also nur im späteren Betrieb dazustöpseln.
Ich warte erstmal noch mit dem auf Null setzen der ersten Sektoren bei Platte2, nicht dass sich bis dahin wieder etwas ändert. So kann ich dann eine nach der anderen Platte fertig machen ohne dass wieder etwas dazwischen kommt.
Ich hab trotzdem mal die ersten drei Sektoren der Platte2 mit angehangen. Als Bin nehme ich mal an, dass du diese als Rohform haben möchtest.
 

Anhänge

  • Platte1u2_0-2.zip
    2,8 KB · Aufrufe: 445
Das verwirrt mich jetzt etwas.
Bei einem RAID5 mit 4 Platten und einer Stripesize von 64K (128 Sektoren) befinden sich auf den Sektoren 0-127
- auf Member 1 die RAID-Volume Sektoren 0-127
- auf Member 2 die RAID-Volume Sektoren 128-255
- auf Member 3 die RAID-Volume Sektoren 256-383
- auf Member 4 die Parity der Daten von Member1/2/3

Der Inhalt des RAID-Volumes von 3TB besteht normalerweise aus dem MBR auf Sektor 0, den GPT-Informationen auf Sektor 1-33 und ab 34 einer unbenutzen "Microsoft reserved Partition", wo auch alter Quatsch eines früheren Platteninhaltes drinnenstehen kann.

Der Inhalt vorne von Member 1 stimmt mit dem Inhalt des GPT-Mirrors am Ende des RAID-Volumes überein (mit den als Einzeldrive von Win7 vorgenommenen falschen Korrekturen auf die Größe von 1TB) und enthält eine einfache Partition in der Größe von 3TB.

Der jetzt von Dir gepostete Inhalt von Platte2 zeigt aber ebenfalls einen MBR eines GPT-Datenträgers, und in den GPT-Informationen den Aufbau eines 3TB Volumes (was auf einer 1TB Platte nur durch Verwendung als RAID-Memberdisk zustande kommen kann), wo aber ein dynamisches GPT-Volume eingerichtet wurde. Ich verfluche die hirnlosen Idioten, welche sich das GPT-Format ausgedacht haben; Im GPT-Header sind großzügig 420 von den 512 Bytes unbenutzt, und keiner ist auf die Idee gekommen, da einen Timestamp der Erstellung und letzten Änderung reinzustellen. So kann man nur vermuten, wann das angelegt wurde:
Ich denke, das stammt aus einer Experimentierzeit, als Du den RAID angelegt hast und die Platte2 damals in der Reihenfolge die erste Memberplatte des Arrays war.

Ich kann natürlich nicht hellsehen, was Du in den Ewigkeiten, die Du den RAID zu rekonstruieren versucht hast, alles angestellt hast - von Änderung der Reihenfolge der Anschlüsse, Neudefinition des Arrays und nochmaligem Initialisieren+Partitionieren des RAID-Volumes, wie es einige Schlaumeier in den Weiten des Internet als Wiederherstellungsmaßnahme (ohne Ahnung, was dabei alles schieflaufen kann) empfehlen.
Was seit dem Zerfall des Arrays passiert ist, musst schon Du mir sagen...
Wenn Du das nicht mehr lückenlos schildern kannst, dann zumindestens ungefähr - dann können wir anhand einiger weiteren Checks die Ereignisse rekonstruieren.

Bis dahin solltest Du keine weiteren Änderungen an den Memberplatten vornehmen, das Löschen dieser Bereiche auf Member2+3 aus dem Vorpost ist also zu unterlassen, damit keine Informationen verlorengehen, bevor wir die gesichtet haben.

Bevor wir weitermachen, hätte ich gerne Antwort auf die wesentlichen Fragen
- Hast Du in Versuchen der Wiederherstellung seit dem Zerfall des RAID den Array neu aufgebaut, und als dynamischer GPT initialisiert ?
- oder kannst Du Dich noch erinnern, das früher bei der Einrichtung mal probiert zu haben, dann den RAID aufgelöst und neu erstellt zu haben, und dieser Volume seither (bis zum Zerfall) als einfacher GPT-Datenträger mit einer Partition verwendet wurde ?
 
Zuletzt bearbeitet:
Das einzigste was bei der Platte 2 im Windows auffällig ist, diese wird glaub als Dynamischer Datenträger eingebunden.
Ich mach dann heute zu Hause mal Abbilder der ersten drei Sektoren der anderen zwei Memberplatten. Vielleicht ist hier auch selbiges passiert.

Ansonsten hatte ich die Platten nur im Windows mit Datenrettungssoftware für Raid in Betrieb. Danach aufgrund von Hinweisen auf korrigierbare Metadaten bin ich dann zu dem Schritt Sektoren bearbeiten übergegangen, wovon der Rest hier schon bekannt ist.
 
Ein Relikt von früher, als Du mit dem 3TB RAID beim Einrichten herumprobiert hast?
Von alleine initialisiert sich ein Datenträger nicht auf GPT dynamisch mit einem 3TB dynamischen Bereich (und schon gar nicht als Einzelplatte)
Fortsetzung am abend.
 
Ich hab glaub damals mal Raid0 und Raid5 mit dem ICH10 getestet. Könnte seien dass ich die auch mal normal im System hatte, aber das weiß ich nicht mehr so genau.
Im Grunde waren die 4 Festplatten von beginn an als Raid5 gedacht, schon bei der zusammenstellung des Systems.
 
Nun, anhand der RAID-Metadaten ist die letzte Konfiguration der Plattenreihenfolge ja bekannt. Daher auch die erste Memberplatte, deren MBR und GPT sowie der Mirror die erwarteten (wenn auch tw falschen) Werte beinhalten.
Also können wir den Inhalt der Platte2 eigentlich ignorieren.
Lassen wir das angedachte Löschen der Platte2 mal weg.

Lösche nur auf Platte1 den Sektor 0.

dann baust Du den RAID5 neu auf:
dazu musst Du alle 4 Memberplatten wieder in der Reihenfolge
Serial=S27EJ9FZ301705
Serial=S27EJ9FZ301706
Serial=S246J9CZ703862
Serial=S27EJ9FZ301710
an den Controller hängen.

Als erstes ist ein "reset all to non-RAID Disks" vorzunehmen,
dann den RAID5 wieder mit den 4 Platten, mit Name: Volume_0000, maximaler Größe, und Stripesize 64K definieren.

Danach muss obige Reihenfolge angezeigt werden (vorher zeigt er das, was in den Metadaten stand) Wenn nicht, RAID wieder auflösen, umkabeln, neudefinieren.

Passt es, dann die Platte3 entfernen, der RAID sollte damit degraded Status bekommen

Der Array sollte als uninitialisiertes Volume in der Datenträgerverwaltung sichtbar sein.
Nicht initialisieren!
vorher machen wir noch ein paar Checks, ob alles passt.
 
Eine Sache noch bevor ich das jetzt mache.
Die Platte3 hat ja noch veralteten Raid-Inhalt. Das stört jetzt nicht wenn ich die Aktionen ausführe?
Ergänzung ()

Das Reset to non-Raid im Windows oder im Boot-Menü vornehmen? Würde das einen Unterschied machen?
Ergänzung ()

Mein Fehler, man sollte mal bis Ende lesen :D
 
Erstmal den MBR auf der Platte1 plattmachen, damit keinerlei Operationen durch das System am Array mehr möglich sind

Mach das Reset und die Neudefinition dort, wo Du es früher mal gemacht hast.
(Es gibt unterschiedliche Arraygrößen je Methode, die wir sonst korrigieren müssten)
==> Raid Status normal
Danach sollst Du die Platte 3 ja wieder abklemmen
==> Raid Status degraded

damit haben wir die Anfangsbedingungen vor Ausfall der zweiten Platte wiederhergestellt.

dann führen wir ein paar Überprüfungen Durch, ob alles passt, und danach wird der MBR+GPT korrigiert aufgespielt
 
Das Raid ist jetzt wieder im Status Degraded.
Aktueller Stand letzte 4 Sektoren der Platte3 und Intel Matrix Storage Manager
 

Anhänge

  • Platte3-letzte4.zip
    1,6 KB · Aufrufe: 457
  • Volume0000_1.png
    Volume0000_1.png
    49,2 KB · Aufrufe: 477
  • Volume0000_2.png
    Volume0000_2.png
    48,1 KB · Aufrufe: 457
  • Volume0000_3.png
    Volume0000_3.png
    50,3 KB · Aufrufe: 451
  • Volume0000_4.png
    Volume0000_4.png
    51,3 KB · Aufrufe: 459
Sieht gut aus. werde mir die Platte3 Daten mal durchsehen, dauert etwas, bis ich dazukomme. Antwort dazu ca 18:30
 
Beim durchstöbern der alten Sektordaten fällt mir derzeit ein was auf.
Kann es seien dass die Platte3 (Anschluss2) als vierte im Raid aufgeführt war?


Damals war mir mal wirklich eine HD103SJ in den Jordan gegangen am Anschluss2. Die Jetzige Platte3 war die Tauschplatte für diese. Das Raid wurde danach neu aufgebaut. Deshalb hat diese auch eine etwas andere Seriennummer.
 
Am neuaufgebauten Raid5 die relevanten Daten von Platte3
.. Map Name: "Volume_0000"
Sectors: 5860560896
# Sectors/member: 1953520648
# Stripes/member: 15261878
# Sectors/Stripe: 128 ==> stripesize=64KB
Volume status: UNINITIALIZED (das ist jetzt auf DEGRADED gewechselt)
RAID Level: RAID-5 Array
# member disks: 4
member order 1: HDD[0] <Serial=S27EJ9FZ301705>
member order 2: HDD[1] <Serial=S27EJ9FZ301706>
member order 3: HDD[2] <Serial=S246J9CZ703862> (die ist dann weg)
member order 4: HDD[3] <Serial=S27EJ9FZ301710>

sind zur allgemeinen Begeisterung alle gleich wie vorher :)

Nun in die Datenträgerverwaltung geschaut; an der Datenträgernummer des Arrays
+1 im HxD geöffnet, sollte (vergleich des Klartextes rechts reicht)
- am Sektor 1 und 2 das gleiche stehen wie im File Platte1_0-4400.txt ab Offset hex 0000000200
- am letzten Sektor des Arrays ( Rechts mit dem >| Button) das gleiche wie am Ende der Datei Platte1_e8e0b5bc00-e8e0b5fff0.txt
- ab Sektor 128 (der ist wahrscheinlich mit 0x00 gefüllt im Sektor 129 und 130 das gleiche wie in der Datei Platte2_0-2.txt ab Offset hex 000000200

Dann scheint alles am rechten Platz zu sein.
Für die Korrektur der Beginnsektoren des Arrays lass mir noch 2-3 Stunden Zeit, ich bin noch nicht dazugekommen, die zu erstellen und muss dazu erst nach Hause.
Ergänzung ()

iamhermes schrieb:
Beim durchstöbern der alten Sektordaten fällt mir derzeit ein was auf.
Kann es seien dass die Platte3 (Anschluss2) als vierte im Raid aufgeführt war?


Damals war mir mal wirklich eine HD103SJ in den Jordan gegangen am Anschluss2. Die Jetzige Platte3 war die Tauschplatte für diese. Das Raid wurde danach neu aufgebaut. Deshalb hat diese auch eine etwas andere Seriennummer.

Das lässt sich durch nichts belegen - außer, dass die Platte 2 früher an der Position 1 war und drauf ein dynamischer GTP-Datenträger mit 3TB. Die restliche Reihenfolge lässt sich nur schwer feststellen (bestenfalls durch seither nicht überschriebene Sektoren, wenn früher mehr drauf war als jetzt), weil keine RAID-Metadaten von damals mehr auf diesen Platten sind. Bestenfalls auf der damals rausgefallenen und getauschten.
 
Ernst@at schrieb:
Nun in die Datenträgerverwaltung geschaut; an der Datenträgernummer des Arrays
+1 im HxD geöffnet, sollte (vergleich des Klartextes rechts reicht)
- am Sektor 1 und 2 das gleiche stehen wie im File Platte1_0-4400.txt ab Offset hex 0000000200
Sektor 1 und 2 ist ohne Inhalt.
- am letzten Sektor des Arrays ( Rechts mit dem >| Button) das gleiche wie am Ende der Datei Platte1_e8e0b5bc00-e8e0b5fff0.txt
Der letzte Sektor 500118191 ist leer. Auch die davor.
- ab Sektor 128 (der ist wahrscheinlich mit 0x00 gefüllt im Sektor 129 und 130 das gleiche wie in der Datei Platte2_0-2.txt ab Offset hex 000000200
dort ist auch nix.


Ich habe in der Zwischenzeit auch mal Texte gesucht um zu prüfen ob das auch alles passt.
Von Sektor 33547647 auf 33547648 müsste ja ein Festplattenwechsel stattfinden vom Stripe (64kb -> 128 Sektoren zu je 512 Byte). Passen tut dies an der Stelle. Auch 128 Sektoren später ist dies noch so korrekt und auch 128 davor.

Ergänzung ()

Das lässt sich durch nichts belegen - außer, dass die Platte 2 früher an der Position 1 war und drauf ein dynamischer GTP-Datenträger mit 3TB. Die restliche Reihenfolge lässt sich nur schwer feststellen (bestenfalls durch seither nicht überschriebene Sektoren, wenn früher mehr drauf war als jetzt), weil keine RAID-Metadaten von damals mehr auf diesen Platten sind. Bestenfalls auf der damals rausgefallenen und getauschten.

Die über den Jordan gegangene war nicht mehr zugreifbar. Diese konnte sich laut SMART nicht mehr Initialisieren und ging anschließend in die RMA.
 
Zuletzt bearbeitet:
Irgendwas ist da jetzt total schiefgelaufen. Der letzte Sektor des Arrays sollte eigentlich 5860560895 sein.
Melde mich in einer Stunde wieder.
Ergänzung ()

Warst Du vielleicht auf einer falschen Platte? Durch die Neudefinition des RAID hat sich ja was in der Reihenfolge der Datenträger geändert - welcher ist das jetzt in der Datenträgerverwaltung? Welche Größe wird da angezeigt? Mach mal einen Screenshot
 
Argh, das war die SSD die ich da geprüft habe :freak:
Das Fällt mir auch gerade auf, da 500.118.191 Sektoren mit 512er Einteilung der SSD und 5.860.560.895 Sektoren vom Verbund....

Jetzt hab ich den richtigen Datenträger. Die Sektoren stimmen jetzt überein. Die 128 ist leer, die zwei Nachfolgenden sind gleich.
Der Letzte stimmt auch.

Schande auf mein Haupt
 
irren ist erlaubt - solange es mit keinem Datenverlust einhergeht :D
Dürfen wir den letzten Akt auf morgen verschieben? Ich bin heute irgenwie von der Rolle.
Sonst passiert da noch was böses...
 
Hat sich eh schon um einiges verschoben. Da sollte es auf die paar Stunden nicht mehr drauf ankommen ;)
 
Na gut, dann klatschen wir eben mal den richtigen Inhalt auf die Platte

HxD Aufruf unter User mit Administratorrechten (oder per rechtklick - Ausführen als ...)

- Menü: Extras/open disk/physical disk/um 1 mehr als in der Datenträgerverwaltung (Häkchen bei "open as readonly" diesmal entfernen)

Überprüfen, ob Du auf der richtigen Platte gelandet bist:
in der Menüzeile muss rechts Sector [Eingabefeld] of 5860560896 stehen; wenn nicht - ABBRECHEN
Im Sektor 0 sollte überall hex 00 stehen - wenn nicht, ABBRECHEN und nachfragen

========= restore korrigierten MBR+GPT
- Menü: File/Open --> den entzippten Platte1neu.bin wählen
- Strg+A (markiert alles)
- Strg+C (Kopiert es in die Zwischenablage)
- Menü: File/Close (es erscheint wieder die Anzeige der hard disk)

- Menü: Edit/select block/start: 0 ; length: 400, hex, OK
- Strg+V (überträgt es aus der Zwischenablage - bei popup "File Size change": ABBRECHEN, ohne zu speichern!- Menü: File/Save (schreibt es auf die Platte zurück)
- HxD beenden


Einen Neustart hinlegen.
In der Datenträgerverwaltung sollte der Partition am RAID ein Laufwerksbuchstabe zugewiesen worden sein.

Keine Explorer-Zugriffe auf die Partition

Gehe erst mal in die Eingabeaufforderung und mache dort ein "chkdsk laufwerksbuchstabe:" OHNE Parameter.
Wenn das ohne Fehlermeldungen beendet, sollte alles wieder vorhanden und verwendbar sein.
 

Anhänge

  • Platte1neu.zip
    620 Bytes · Aufrufe: 430
Zuletzt bearbeitet:
Ist oben im Anhang. Wollt nur noch mal alles durchlesen, bevor Du beginnen kannst.
 
Zurück
Oben