Recovern eines Software RAID-5 unter Windows XP

tajbender

Cadet 2nd Year
Registriert
Aug. 2004
Beiträge
17
Hallo,

ich habe eine Frage bzgl. eines kleinen Problems, vielleicht kann sich ja auch Ernst@at dazu äußern: Ich habe vor einigen Jahren unter Windows XP - ich meine es war SP2 - einen Software-RAID-Patch installiert, bei dem per Batch-Datei einige System-Dateien manipuliert wurden, um die volle Software-RAID-Funktionalität auch unter WinXP Pro freizuschalten...

Mittels eines solch gepatchten WinXPs habe ich dann 3 SATA-HDDs an das Board gehangen, und per Datenträgerverwaltung ein Software-RAID-5 erzeugt um dort wichtige Dateien wie vor allem Quellcodes abzulegen. Formatiert war das Ganze unter NTFS.

Nun zu meinem Problem: An der Hardware des Rechners hat sich seither an sich nicht viel geändert, allerdings musste das Netzteil samt Boot-HDD ausgetauscht werden (die freilich nicht zum RAID-Verbund gehörte). Damit einhergehend wurde auch Windows neu installiert.

Danach habe ich einige Jahre gar nicht erst versucht, das RAID wieder anzuhängen, bis vor einigen Monaten: Die drei Platten wurden von der Datenträgerverwaltung auch erkannt, allerdings konnte keine Partition recovert werden, bzw. genauer gesagt wusste ich in der Situation gar nicht, welche Schritte hierfür manuell vorzunehmen wären...

Danach habe ich da Platten abgehangen und das Problem auf die lange Bank geschoben :D

Lange Rede, kurzer Sinn: Kann mir also jemand Tipps geben, welche Schritte notwendig sind, um den RAID-5-Verbund der drei HDDs, die physikalisch meines Erachtens noch in Ordnung zu sein scheinen, wieder als solchen einbinden zu können, am Besten natürlich so, dass Datenverlust auszuschliessen ist?

Die Vorgaben sind folgende:
  • Hardware im Prinzip weiterhin identisch
  • Soft-RAID wurde erstellt/betrieben unter Windows XP, wahrscheinlich SP2, jetzt vorhanden SP3, Windows inzwischen komplett neu und frisch installiert; Soft-RAID-Patch wurde wieder eingespielt - oder ist für SP3 gar ein neuer nötig?
  • SATA-Anschlüsse sind auf dem Board genug vorhanden, allerdings sind 2 der freien Stecker mit der Intel-Southbridge verbunden, zwei weitere mit einem Silicon Image SATA-Controller-Chip
  • Externe Datenträger sind vorhanden; Das RAID soll also gar nicht mehr langfristig ins System eingebunden werden. Wenn ich es wieder zum Laufen bekäme um ein Vollbackup der darauf vorhandenen Daten vornehmen zu können wäre ich schon mehr als glücklich :D
  • Grund- bis mittlere Kenntnisse unter UNIXoiden Betriebssystem sind vorhanden, falls dies also helfen könnte, würde es keine Hürde dastellen bis in die BASH hinab zu steigen
Meine Fragen:
  1. Die Reihenfolge, unter welchen physischen Ports die HDDs Anschluss an das MB finden, sollte doch eigentlich egal sein?
  2. Evtl. damals vergebene Parameter wie Stripe-Size kenne ich nicht mehr, Problem?
  3. Würde es helfen, jeweils ein Vollbackup der drei HDDs auf Blockebene vorzunehmen, bevor der Rettungsversuch vergenommen werden soll? Mit welchen Software-Mitteln könnte und sollte dies dann versucht werden?
  4. Letztendlich - ja klar - wie gehe ich vor, die insgesamt maximal 400GB Daten auf externe Medien zu sichern?

Ich weiß, das ist viel Text, aber vielleicht nimmt sich ja jemand die Zeit und die Muse, ihn zu verinnerlichen und mir bei dem Problemchen zu helfen. Ich weiß auch, dass Google mindestens eine Handvoll Software-Tools ausspuckt, die versprechen bei derartigen Problemen zu helfen, jedoch möchte ich prinzipbedingt die Zugriffe auf den Plattenstapel möglichst vermeiden, bevor ich einen Plan habe wie ich die Daten retten kann... Außerdem kosten diese Tools teilweise auch noch unverschämt viel Geld, bedenkt man, dass man sie nur einen Tag benutzen würde - aber der Rettung meiner alten Daten wäre mir auch das wert, vorausgesetzt mir könnte jemand eine entsprechende Empfehlung aus eigener Erfahrung geben, sprich, dass sich die Investition auch lohnen würde...

Aus diesem Grunde wäre ich für jegliche Hilfe mehr als verbunden.

Vielen Dank und viele Grüße,
tajbender
 
Würde es helfen, jeweils ein Vollbackup der drei HDDs auf Blockebene vorzunehmen, bevor der Rettungsversuch vergenommen werden soll? Mit welchen Software-Mitteln könnte und sollte dies dann versucht werden?

Wenn du den Platz hast kann das aufjedenfall nicht schaden.

Ansonsten würde ich alles was jetzt kommt ignorieren bis Ernst@at aufschlägt.
 
M-X schrieb:
Wenn du den Platz hast kann das aufjedenfall nicht schaden.

Ansonsten würde ich alles was jetzt kommt ignorieren bis Ernst@at aufschlägt.

Hallo, und Danke erstmal für die rasche Antwort. Ich hätte eine 1,5TB große externe HDD, auf der sicher noch 1,3 TB frei wären, allerdings per USB 1.0 angebunden.

Die drei RAID-HDDs sind jeweils 200GB groß, also netto 600GB, brutto <400GB an Daten, die zu sichern wären.

Wäre also kein großes Problem, die Partitionen so wie sie nun sind wegzusichern, per Linux mittels DD?!?
 
Moin tajbender,

dein Problem interessiert mich sehr. Stehe vor einem ähnlichen Problem. (Habe seit 1 1/2 Jahren zwei Platten, welche in einem Raid 0 liefen, zu rekonstruieren.) Das größte Problem ist die Zeit, die Du für diese Aufgabe zu opfern hast ... ;) .....

Doch nun mal ein Versuch der praktischen Hilfe. Melde Dich einfach mal, Interesse vorausgesetzt, mit ner PM bei mir. Kann gerne versuchen Dich mit ein bißchen "I/O" zu unterstützen.

Greetz

taschanga

PS. Respekt....gutes Deutsch, und eine präzise Beschreibung der Problematik ;)
 
Zu den Fragen meine Antworten
1. Die Reihenfolge, unter welchen physischen Ports die HDDs Anschluss an das MB finden, sollte doch eigentlich egal sein?
Ja, weil die Reihenfolge und Lage der dem "Parity"-Volume zugehörigen Partitionteile in der dyn. Datenbank gespeichert ist
2. Evtl. damals vergebene Parameter wie Stripe-Size kenne ich nicht mehr, Problem?
Meines Wissens nach kann man keine wählen
3. Würde es helfen, jeweils ein Vollbackup der drei HDDs auf Blockebene vorzunehmen, bevor der Rettungsversuch vergenommen werden soll? Mit welchen Software-Mitteln könnte und sollte dies dann versucht werden?
Üblicherweise finden Rettungsversuche IMMER im Lesemodus statt, die geretteten Daten IMMER auf andere Datenträger ausreichender Kapazität. Jedes Tool, welches anders verfährt, ist unseriös. Mit meinem patentierten Herumgefrickel auf den Original-Raid-HDDs kann man nicht in allen Fällen arbeiten.
4. Letztendlich - ja klar - wie gehe ich vor, die insgesamt maximal 400GB Daten auf externe Medien zu sichern?
Falls das nötig sein sollte, ist ein Image jedes der physischen Volumes das Mittel der Wahl. Da verschiedene Tools dafür unterschiedliche Formate verwenden(die schlimmstenfalls nur wieder auf eine andere oder die gleiche physische Platte zurückgespielt werden können) sollte eines gewählt werden, welches auch von den RAID-reconstruction Softwareprodukten eingelesen werden kann. Alle dieser Produkte sind in kostenloser Trial-Version erhältlich, welche eine Analyse durchführen und so den möglichen Erfolg prognostizieren, bevor man die Lizenz dafür erwirbt.

Was sonst noch zu dem Thema zu sagen ist:

RAID5("Parity") ist im Windows je Version nur in ausgewählten Editions von MS verfügbar gemacht(downgrade der anderen) und kann mit einem Registry-Patch (und soweit ich mich erinnere, auch zusätzlichen executable Codes) im WinXP verfügbar gemacht werden.

Wenn jetzt das System neu aufgesetzt wurde und der Patch wieder aktiviert, müsste ein Probelauf auf 3 anderen Platten ein solches Parity-Set erzeugen und verwenden lassen. Wenn ich mich richtig an ein paar vor Jahren durchgeführte Experimente erinnere, kann man auf virtuellen Platten keine dynamischen Datenträger anlegen, sonst könnte man das alles auf einer einzigen physischen HDD simulieren. In einer VM wäre es aber kein Problem.

Prinzipiell sollte eine Übernahme des Parity-Sets auch in jedes System(2K3,2K8,Win7) möglich sein, welches diese Funktionalität unterstützt. Voraussetzung dazu ist aber, dass die dynDB am Ende jeder Platte, der MBR und der Sektor 6 unversehrt sind.

Nachdem auch die dort angelegten Einträge mit anderen in der Registry übereinstimmen müssen, wird an einem anderen(oder neu erstelltem) System die Einbindung abgelehnt und die Platten müssen mit "fremde dyn. Cluster importieren" aufgenommen werden.

Bei derartigen Software-RAIDs kann sich die Rekonstruktion schwieriger gestalten, mir selbst ist die Art der Parity-Rotation nicht bekannt, die fixe Stripesize wird möglicherweise 64K sein, aber der RAID-Bereich könnte auf jeder Platte an einem anderen Offset beginnen. Lässt sich aber alles in Experimenten und Analyse der Einzelplatten rausfinden. Schlimmstenfalls muss man dazu 3 weitere Platten zu Hilfe nehmen.
taschanga schrieb:
Stehe vor einem ähnlichen Problem. (Habe seit 1 1/2 Jahren zwei Platten, welche in einem Raid 0 liefen, zu rekonstruieren.) Das größte Problem ist die Zeit, die Du für diese Aufgabe zu opfern hast ... ;) .....
Das sind bloss ein paar Stunden, bei einem Software-RAID0("striped") ist es etwas einfacher, weil keine Parity -und damit auch keine Rotation - zu berücksichtigen ist.
 
Zuletzt bearbeitet:
Hallo, und vielen Dank erstmal für die netten Antworten.

Ernst@at schrieb:
Prinzipiell sollte eine Übernahme des Parity-Sets auch in jedes System(2K3,2K8,Win7) möglich sein, welches diese Funktionalität unterstützt. Voraussetzung dazu ist aber, dass die dynDB am Ende jeder Platte, der MBR und der Sektor 6 unversehrt sind.

Nachdem auch die dort angelegten Einträge mit anderen in der Registry übereinstimmen müssen, wird an einem anderen(oder neu erstelltem) System die Einbindung abgelehnt und die Platten müssen mit "fremde dyn. Cluster importieren" aufgenommen werden.
Mal eine prinzipielle Frage: Müsste ein solches Software-RAID-5 unter Windows XP nicht generell völlig selbstständig wieder erkannt und eingebunden werden, auch wenn es sich inzwischen um eine Neuinstallation des OS handelt, oder müsste das RAID in einem solchen Fall tatsächlich manuell eingebunden werden? Wenn ja, wie ginge das eigentlich ;)

Oder, anders ausgedrückt, wenn ich das geschriebene nun richtig verstanden habe, müsste ich im Kontextmenü der Datenträgerverwaltung bei einer der drei HDDs einfach nur den Punkt "fremde dyn. Cluster importieren" anwählen, und ich hätte gute Chancen, dass das RAID wieder erkannt wird? Oder habe ich da nun etwas falsch verstanden? Und finden dabei Schreibzugriffe auf die Platten statt?

Das Problem ist nämlích, oder besser ein weiteres Problem, dass ich aufgrund eines Unfalls derzeit gar nicht zuhause bin und den Rechner somit auch nicht im Zugriff habe... Von daher kann ich jetzt gar nicht sagen, ob solch eine Option angeboten wird oder nicht...

Vielen Dank nochmals für die Antworten,
und viele Grüße,
tajbender
 
wenn ich das geschriebene nun richtig verstanden habe, müsste ich im Kontextmenü der Datenträgerverwaltung bei einer der drei HDDs einfach nur den Punkt "fremde dyn. Cluster importieren" anwählen, und ich hätte gute Chancen, dass das RAID wieder erkannt wird?
Das funktioniert natürlich nur, wenn

1. Das System auch durch den Mod tatsächlich wieder imstande ist, dyn. mirror/stripe/parity Volumes zu bearbeiten (daher der angeratene Test mit Anlegen eines parity-Volumes auf anderen Platten)

2. alle 3 Platten in der Datenträgerverwaltung als "Fremd" ausgewiesen werden und sollte bei Systemwechsel der Normalfall sein. Ist das nicht der Fall, so wurden Informationen auf nicht als "Fremd" erkannten Datenträger im MBR oder am Ende der Platte durch andere Einflüsse überschrieben.
Ist nur eine der Platten davon betroffen und daher nicht einbindbar, dann müsste die Partition trotzdem mountbar und auslesbar sein (da ja RAID5-Redundanz)
 
Okay, also vielen, vielen Dank schon mal an Euch alle, vor allem aber natürlich an Ernst@at :)

Ich melde mich dann wieder, sobald ich den Rechner wieder unter meinen Fittichen habe.
 
Hallo nochmal,

es hat zwar etwas länger gedauert, als gehofft, aber ich habe die Daten tatsächlich retten können. Danke also an Alle!

Ich hab' mit GetDataBack for NTFS Images aller drei Platten erstellt, und dann mit "RaidRecovery for Windows" alle Daten wiederherstellen können.

Hat zwar etwas gedauert, aber das tut ja nicht weh. Insofern haben die Jungs bei Runtime Software (https://www.runtime.org/) einen guten Job gemacht.

Vielen Dank nochmal an Alle für die hilfreichen Tipps!

Gruß,
tajbender
 
Zurück
Oben