Datenrettung: gecrashdes Raid5 an CS407

[SirDarki]

Hallo Zusammen

Ich versuche grad verzweifelt mein Raid 5 auf meiner CS407 wieder zum laufen zum bringen. Dabei orientiere ich mich in erster Linie an den relevanten Threads:
http://www.synology-forum.de/showthread.html?t=261
http://www.synology-forum.de/showthread.html?t=510

Folgender Vorgang:
Erst hat sich Platte 4 defekt gemeldet wodurch das Raid als abgestürzt gemeldet wird. Nach dem auswechseln der Platte (hat früher mit einer anderen Platte auch schon mal gut funktioniert) und dem Neustart der CS meldet sich nun auch die Platte 2 als nicht initialisierbar. Mehrere Neustarts, immer dasselbe Ergebnis. Volumen abgestürzt. Nach Platte 1, die als normal bezeichnet wird sagt mir das Webinterface dass alle folgenden Platten nicht initalisiert seien. Platte 4 ist ja auch Fabrikneu, die anderen aber sollten gehen.

Nun, ich habe mir zuallerest mal alle Platten an einem Linux-System kopiert. Dabei fällt auf dass alle 3 Partitionen auf Platte 1 und 3 problemlos zu kopieren sind, bei Platte 2 hingegen meldet er beim kopieren mit dd bereits einen Fehler, danach beim betrachten mit dem Partitionseditor wird Partition 2 mit Fehler gemeldet. Platte 4 liess sich gar nicht kopieren, da die wohl endgültig hinüber ist und vom System gar nicht erkannt wird

Dann die kopierten Platten (inkl. neuer Platte 4) am CS gestartet, Platte 1 ist normal, die anderen 3 sind nicht initialisiert. Ok, hatten wir ja schon. Nun per Telnet versucht das Raid neu zu bauen:

Sun> mdadm -Sf /dev/md2
mdadm: stopped /dev/md2
Sun> mdadm --assemble --force /dev/md2 /dev/sd[a-d]3
mdadm: no RAID superblock on /dev/sdb3
mdadm: /dev/sdb3 has no superblock - assembly aborted
Sun>

Es scheint dass der Superblock von Platte 2, also genau die Partition die oben schon als Fehlerhaft bezeichnet wurde effektiv ein Problem hat.

Gibt es eine Möglichkeit den Superblock auf Platte 2 (auf der Kopie natürlich) zu reparien? Bin leider überhaupt nicht fit auf LINUX und RAIDS

 

[Supaman]

wenn es auf der partition2 probleme gibt, ist das die swap-partition. wenn platte 4 komplett hinüber ist, würde ich die weglassen und das mal mit 3 platten versuchen:

mdadm --assemble --force -v /dev/md2 /dev/sda3 /dev/sdb3 /dev/sdc3

mit den superblocks kenne ich mich auch nicht aus, ich würde versuchen, die platten mit raid-5 fähiger datenrettungssoftware auszulesen.

 

[SirDarki]

Vielen Dank für die schnelle Antwort.

Die Fehlermeldung mit dem fehlenden/defekten? Superblock auf Platte 2 bleibt dieselbe auch wenn ich Platte 4 aussen vor lasse. Gibt es keine Möglichkeit diesen Superblock zu reparien oder neu generieren zu lassen?

Welche Datenrettungssoftware unter welchem Betriebssystem würdest Du denn empfehlen?

Hab nun zur Sicherheit noch das ganze Spiel explizit ohne Platte 4 am Controller versucht, Ergebnis dasselbe:

Sun> mdadm --stop /dev/md2
mdadm: stopped /dev/md2
Sun> mdadm --assemble --force -v /dev/md2 /dev/sda3 /dev/sdb3 /dev/sdc3
mdadm: looking for devices for /dev/md2
mdadm: no RAID superblock on /dev/sdb3
mdadm: /dev/sdb3 has no superblock - assembly aborted

...ich schätze die Luft wird dünner

 

[SirDarki]

Mal ein Zwischenbericht meinerseits

Zum einen bewährt sich das hantieren mit einer aktuellen UBUNTU Installation recht gut zumal man damit sämtliche auf Linux verfügbaren Tools recht hantlich zur Verfügung hat. Ich spreche hier z.B. von der standardmässig vorhandenen Kopierfunktion dd, der im Kernel bereits integrierten Soft-Raid-fähigkeit, des PartitionsEditors, der einfach nachzuinstallierenden mdadm-Funktion und dem Tool TestDrive.

Zum anderen hat mir das alles bis jetzt recht wenig gebracht, da wie oben schon gesagt Platte 4 des Raid5 komplett nicht mehr ansprechbar ist und bei Platte 2 der Superblock defekt ist und sich auch alternative Superblocks nicht identifizieren liessen. Alle diesbezüglichen Übungen waren bisher erfolglos. Die bei TestDrive angepriesene Suche nach Superblocks kann ich da nirgends finden.....

Damit stehe ich 0,5mm vor meinen Daten, komm aber nicht ran. Linux weigert sich schlicht das Raid zu reassemblieren da er auf Platte 2 keinen Superblock findet. Da hilft alles --force nix.

Der unter Windows laufende UFS Explorer hat mir bis jetzt leider auch nicht weiterhelfen können, da auch hier wohl alle zum Raid gehörenden Platten (wenn auch in den Kopfdaten defekt) angestöpselt sein müssten. Mit nur 3 Platten findet er allerdings nur Datensalat. Hier fragt man sich allerdings auch ob ich evtl. auch etwas wenig Infos hab wie die etlichen Parameter des Raids richtig vorzugeben sind damit überhaupt die richtige Suche durchgeführt wird.

Hat jemand noch weitere Infos oder Ideen?

 

[Supaman]

ich würde auf jedenfall alle 4 platten anschliessen, wenn keine freien sata ports vorhanden sind zur not den rest per usb-gehäuse. die raid parameter müssten sein:

Layout : left-symmetric
Chunk Size : 64K

 

[Supaman]

mit TESTDISK kann man ebenfalls raids/partitionen analysieren und reparieren.
http://www.cgsecurity.org/wiki/Sicherungskopie_des_erweiterten_ext2-/ext3-SuperBlocks_finden
http://www.cgsecurity.org/wiki/TestDisk

sehr guten support für die benutzung von testdisk gibts im computerbase forum:
http://www.computerbase.de/forum/forumdisplay.php?f=78

 

[Supaman]

im linux raid-how-to habe ich noch das hier gefunden:
( quelle )

8.1 Recovery from a multiple disk failure

The scenario is:

* A controller dies and takes two disks offline at the same time,
* All disks on one scsi bus can no longer be reached if a disk dies,
* A cable comes loose...

In short: quite often you get a temporary failure of several disks at once; afterwards the RAID superblocks are out of sync and you can no longer init your RAID array.

If using mdadm, you could first try to run:

mdadm --assemble --force

If not, there's one thing left: rewrite the RAID superblocks by mkraid --force

To get this to work, you'll need to have an up to date /etc/raidtab - if it doesn't EXACTLY match devices and ordering of the original disks this will not work as expected, but will most likely completely obliterate whatever data you used to have on your disks.

Look at the sylog produced by trying to start the array, you'll see the event count for each superblock; usually it's best to leave out the disk with the lowest event count, i.e the oldest one.

If you mkraid without failed-disk, the recovery thread will kick in immediately and start rebuilding the parity blocks - not necessarily what you want at that moment.

With failed-disk you can specify exactly which disks you want to be active and perhaps try different combinations for best results. BTW, only mount the filesystem read-only while trying this out... This has been successfully used by at least two guys I've been in contact with.

 

[SirDarki]

Vielen Dank für die Infos Supaman

Leider ist einiges davon bereits abgehakt. Wie gesagt macht Platte 4 absolut keinen Wank mehr, d.h. weigert sich schon ordentlich am BIOS anzumelden (Ports hab ich genug, extra ein Recovery-System für den Kram angelegt). Ich denke der interne Controller ist abgeraucht, die Platte wird damit weder von Linux noch von Win erkannt und für irgendwas angeboten. Damit kann ich sie auch nicht kopieren oder in ein Soft-Raid einbinden. Ich bräuchte hier also in jedem Fall eine Software welcher ich beibringen könnte dass ich leider nur 3 von 4 Platten hab. Parameter werden jeweils noch ein paar mehr benötigt wobei die von Dir genannten sicher die wichtigsten sind

Bei TestDisk stelle ich grad fest, dass ich wohl irrigerweise der Ansicht war dass die Linux-Variante am gescheitesten wär. Ich werds denn noch mit der Win-Variante versuchen, vieleicht bietet mir das Programm da die genannte Option (Superblocks suchen) die ich unter Linux vergebens gesucht hab.

Und zuletzt noch vielen Dank für den Hinweis bezüglich mkraid. Da werd ich mich wohl noch etwas einlesen müssen und denke dass es in jedem Fall empfehlenswert ist Kopien der Disks zu verwenden aber ein Versuch ist's auf jeden Fall wert.

Greetz
Darki

 

[Supaman]

kleiner tip zur platte: wenn "nur" die elektronik abgeraucht ist, kann man von einer identischen platte die platine umschrauben um an die daten zu kommen

 

[SirDarki]

Auch für diesen Hinweis nochmals vielen Dank.

Ich hab damit auch noch fröhliches Platinentauschen veranstaltet und hatte schlussendlich vermutlich alle (natürlich baugleichen) Platinen auf der bösen Platte 4. Hauptunterschied war dass sich das Laufwerk wieder ordentlich am BIOS angemeldet hat, die Fehlermeldungen danach waren aber noch vor dem Hochfahren des Betriebssystems so zahlreich dass es nicht überraschte dass die Platte weiterhin nicht für was auch immer zur Verfügung stand.

Auch Platte 2 welche im wesentlichen einen defekten Superblock zu beklagen hat wurde zur Sicherheit noch mit verschiedenen Platinen bedacht, Resultat 0=null.

Leider lässt sich auch dieser Superblock nicht wiederherstellen wobei mir noch nicht ganz klar ist ob es nur daran liegt dass TestDisk vieleicht keine Einzel-Partition dahingehend untersuchen kann die Teil eines Raids ist oder wirklich keine potentiellen alternativen Superblöcke auf der Platte sind.

Nun, ich denke der Aufwand wird nun endgültig dem möglichen Resultat nicht mehr gerecht. Darum läuft seit Gestern Abend ein Full-Restore des Backups auf komplett neuer Hardware während ich hier grad die restliche Hardware für die neue Backup-Konfiguration herrichte. Bis Morgen früh wird das Ding wohl durchgelaufen und online sein.

Ich habe mal wieder viel gelernt und kann vor allem UBUNTU jedem emfehlen der kein Linux-Crack ist aber sich (notgedrungen) damit auseinandersetzen muss/darf.

 

[itari]

Bitte, bitte sag uns allen noch einmal, dass eine Datensicherung wirklich wichtig ist

Itari

 

[SirDarki]

...genau, ein Raid5 bietet vieles aber keine Datensicherheit. Also oberstes Gebot: immer ein Backup laufen lassen. Nach Möglichkeit automatisiert und in jedem Fall auf SEPARATER Hardware.

Und vielen Dank an Supaman noch für die vielen guten Tips.

 

[SirDarki]

So, nochmals zur Info für die "interessierten"

Nach dem Restore und Betrieb meiner Serverdaten auf anderer Hardware ist die CS 407 nun mit neuen HD's wieder seit einigen Tagen in Betrieb, nämlich unter anderem als Backup-Laufwerk für den neuen Server .... und siehe da, das Ding läuft wieder tadellos und ohne zu meckern.

Fazit:
Der Blitz kann DOCH zwei mal zur selben Zeit am selben Ort einschlagen, also grad 2 HD's die gleichzeit den Dienst im Raid 5 quittieren.

Ich weiss, das ist der falsche Ort hier (wer hier stöbert hat bereits zerschossene Daten) aber trotzdem: ein Backup ist immer und in jedem Fall zwingend erforderlich wenn man nicht irgendwann mit abgesägten Hosen dastehen will.