[how-to] Defektes Raid-5 wiederherstellen

[Dataset]

Danke für die schnelle Antwort - habe noch Fragen:
0. Ich habe nur den für Raid5 hier im Forum angegeben mdadm-Komplettbefehl eingegeben, gibt es noch andere Varianten/Zusatzbefehle?
1. Muß ich zur Datenrettung das Raid5 wieder am PC restaurieren, wenn ja - kann ich da einen beliebigen SATA-Raid-Controller nehmen?
2. Wenn ich die Datenrettung wie hier im Forum beschrieben unter Linux vornehme, wie komme ich dann an die Daten für Windows heran?

 

[Supaman]

0. Ich habe nur den für Raid5 hier im Forum angegeben mdadm-Komplettbefehl eingegeben, gibt es noch andere Varianten/Zusatzbefehle?

es gibt noch weitere parameter wie z.b. die spezifikation des superblocks. dafür gibts aber keine allgemeingültige anleitung, sondern man muss dann schon etwas tiefer in die materie eintauchen und wissen, was man da grade macht.

1. Muß ich zur Datenrettung das Raid5 wieder am PC restaurieren, wenn ja - kann ich da einen beliebigen SATA-Raid-Controller nehmen?

es sollte was gängiges sein, was von einer standard-linux live cd erkann wird, z.b. billig controller mit solicon image chip, LSI megaraid oder Intel chipsatz. ansonsten halt manuell die treiber nachladen, als laie wirds da aber etwas fummeliger.

2. Wenn ich die Datenrettung wie hier im Forum beschrieben unter Linux vornehme, wie komme ich dann an die Daten für Windows heran?

umkopieren auf eine NTFS-plattte (sofern der dazugehörige treiber unter linux geladen wurde oder umkopieren auf eine ext2/ext3 platte und unter windows den ext2/ext3 treiber installieren.

 

[PeterG]

Hi,
ich habe mich gezwungenermaßen bei einem eigentlich vollkommen funktionsfähigen System nach einen Komplettausfall nach Neustart (näheres hier) auch mit dieser Thematik beschäftigen müssen. Eigentlich müßten die Daten in Ordnung sein, so dass ich mich auch an der Wiederherstellung versucht habe. Das sieht leider so aus:

DS-01> mdadm --assemble --force -v /dev/md2 /dev/sda3 /dev/sdc3 /dev/sdd3
mdadm: looking for devices for /dev/md2
mdadm: /dev/sda3 is identified as a member of /dev/md2, slot 0.
mdadm: /dev/sdc3 is identified as a member of /dev/md2, slot 2.
mdadm: /dev/sdd3 is identified as a member of /dev/md2, slot 3.
mdadm: forcing event count in /dev/sdc3(2) from 18 upto 40
Segmentation fault (core dumped)

Die Fehlermeldung sagt mir nichts; googlen hat mir nur die Information gebracht, das sei ein Fehler der verwendeten Version von mdadm und bei der älteren Version nicht vorhanden (nützt mir nur leider nix). Kann ich da noch etwas machen, bevor ich das Raid entferne und neu erstelle?

Gruß
Peter

 

[Supaman]

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

was ist mit /dev/sdb3? kannst du ruhig mit angeben, wenn die nicht eingebunden werden kann, wird das i.d.r. automatisch erkannt.

 

[PeterG]

Hi,
das war irrtümlich ein Copy eines Versuchs, wo ich sie weggelassen hatte, weil bei der Standardvariante die Fehlermeldung auf sdb3 bezogen war und ich mal sehen wollte, ob sich was ändert, wenn ich sie weglasse (was leider nicht der Fall ist).

Vielleicht mal der aktuelle Stand vollständiger:

DS-01> mdadm --query --detail /dev/md2
/dev/md2:
        Version : 00.90
  Creation Time : Fri Jan 23 14:27:38 2009
     Raid Level : raid5
     Array Size : 2920857600 (2785.55 GiB 2990.96 GB)
  Used Dev Size : 973619200 (928.52 GiB 996.99 GB)
   Raid Devices : 4
  Total Devices : 1
Preferred Minor : 2
    Persistence : Superblock is persistent

    Update Time : Sat May 16 23:53:42 2009
          State : clean, degraded
 Active Devices : 1
Working Devices : 1
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 64K

           UUID : 96d08ec9:be7a1dde:6a768949:ae6babf0
         Events : 0.42

    Number   Major   Minor   RaidDevice State
       0       8        3        0      active sync   /dev/sda3
       1       0        0        1      removed
       2       0        0        2      removed
       3       0        0        3      removed

Nach stoppen von /dev/md2 Versuch der Wiederherstellung (Platte 5 habe ich momentan abgestöpselt; die ist als Basic - volume2 - eingerichtet gewesen; werde ich da denn wenigstens wieder rankommen? Momentan ist mir das zu unsicher...):

DS-01> mdadm --assemble --force -v /dev/md2 /dev/sd[a-d]3
mdadm: looking for devices for /dev/md2
mdadm: /dev/sda3 is identified as a member of /dev/md2, slot 0.
mdadm: /dev/sdb3 is identified as a member of /dev/md2, slot 1.
mdadm: /dev/sdc3 is identified as a member of /dev/md2, slot 2.
mdadm: /dev/sdd3 is identified as a member of /dev/md2, slot 3.
mdadm: forcing event count in /dev/sdb3(1) from 18 upto 44
Segmentation fault (core dumped)

Tja, und da komme ich dann nicht mehr weiter. Die Option mdadm 2.6.5 zu verwenden habe ich ja nicht... was tun?
Ein aktuelles Backup (einen knappen Tag alt, was da nicht drauf ist, habe ich noch anderswo) habe ich auf Platte 5 (deshalb möchte ich den Inhalt ungern verlieren), etwas älteres Backup auf einer externen Platte. Ärgerlich ist der Verlust des Raid vor allem wegen des mit der Wiedereinrichtung des Systems (3rd-party Apps etc.) verbundenen Aufwands; da gibt es ja leider keine Backupmöglichkeit. Wenn auf der DS möglich, würde ich das Raid5 daher schon gerne retten...

Gruß
Peter

 

[Supaman]

Nach stoppen von /dev/md2 Versuch der Wiederherstellung (Platte 5 habe ich momentan abgestöpselt; die ist als Basic - volume2 - eingerichtet gewesen; werde ich da denn wenigstens wieder rankommen? Momentan ist mir das zu unsicher...):

ja geht, sollte kein problem sein. hier die anleitung zum auslesen eine basis-volumen. http://forum.synology.com/wiki/index.php/How_to_manually_mount_a_USB_Hard_Disk,_including_a_disk_that_was_part_of_a_RAID1_array

 

[Supaman]

DS-01> mdadm --assemble --force -v /dev/md2 /dev/sd[a-d]3
mdadm: looking for devices for /dev/md2
mdadm: /dev/sda3 is identified as a member of /dev/md2, slot 0.
mdadm: /dev/sdb3 is identified as a member of /dev/md2, slot 1.
mdadm: /dev/sdc3 is identified as a member of /dev/md2, slot 2.
mdadm: /dev/sdd3 is identified as a member of /dev/md2, slot 3.
mdadm: forcing event count in /dev/sdb3(1) from 18 upto 44
Segmentation fault (core dumped)

Tja, und da komme ich dann nicht mehr weiter. Die Option mdadm 2.6.5 zu verwenden habe ich ja nicht... was tun?

mir würden noch 2 dinge inefallen: man kann mdadm auch sachen welchen superblock er benutzen soll, poaramter hab ich grade nicht zur hand. wenn die neue mdadm version ärger macht, könnte man eine single platte einbauen und dort eine alte firmware aufspielen, die platten nach dem hochfahren einstecken und von hand mounten, und dann mal mdadm testen - wäre aber etwas "experimentell".

Ein aktuelles Backup (einen knappen Tag alt, was da nicht drauf ist, habe ich noch anderswo) habe ich auf Platte 5 (deshalb möchte ich den Inhalt ungern verlieren), etwas älteres Backup auf einer externen Platte. Ärgerlich ist der Verlust des Raid vor allem wegen des mit der Wiedereinrichtung des Systems (3rd-party Apps etc.) verbundenen Aufwands; da gibt es ja leider keine Backupmöglichkeit. Wenn auf der DS möglich, würde ich das Raid5 daher schon gerne retten...

am pc kann man das mit der richtigen software noch auslesen.

 

[PeterG]

mir würden noch 2 dinge inefallen: man kann mdadm auch sachen welchen superblock er benutzen soll, poaramter hab ich grade nicht zur hand.

Den Parameter könnte ich über die Hilfe von mdadm wohl finden, aber ich was müßte ich dort dann für den superblock angeben?

Gruß
Peter

 

[PeterG]

Hi,
noch eine Ergänzung:

DS-01> mdadm --detail --scan
ARRAY /dev/md0 level=raid1 num-devices=5 metadata=00.90 UUID=5949688c:a64a22ed:5b6fc788:815db2ac
ARRAY /dev/md1 level=raid1 num-devices=5 metadata=00.90 UUID=0b295956:c8fc1c22:4446b136:802538b0
ARRAY /dev/md2 level=raid5 num-devices=4 metadata=00.90 UUID=96d08ec9:be7a1dde:6a768949:ae6babf0
ARRAY /dev/md3 level=raid1 num-devices=1 metadata=00.90 UUID=4e770663:ba7998bc:3dd1c73e:0545d857

Irgendwoher hat das System also die Info, dass zu /dev/md2 als RAID5 4 Platten gehören; läßt sich da irgendwie anknüpfen?

Gruß
Peter

 

[PeterG]

Hi,
Infos bekommt man mit mdadm ja wirklich eine Menge; wenn ich das jetzt auch noch in ein funktionierendes RAID umsetzen könnte:

DS-01> mdadm --examine /dev/sd[a-d]3
/dev/sda3:
          Magic : a92b4efc
        Version : 00.90.00
           UUID : 96d08ec9:be7a1dde:6a768949:ae6babf0
  Creation Time : Fri Jan 23 14:27:38 2009
     Raid Level : raid5
  Used Dev Size : 973619200 (928.52 GiB 996.99 GB)
     Array Size : 2920857600 (2785.55 GiB 2990.96 GB)
   Raid Devices : 4
  Total Devices : 1
Preferred Minor : 2

    Update Time : Sun May 17 01:08:03 2009
          State : clean
 Active Devices : 1
Working Devices : 1
 Failed Devices : 3
  Spare Devices : 0
       Checksum : e4ea7f0f - correct
         Events : 46

         Layout : left-symmetric
     Chunk Size : 64K

      Number   Major   Minor   RaidDevice State
this     0       8        3        0      active sync   /dev/sda3

   0     0       8        3        0      active sync   /dev/sda3
   1     1       0        0        1      faulty removed
   2     2       0        0        2      faulty removed
   3     3       0        0        3      faulty removed
/dev/sdb3:
          Magic : a92b4efc
        Version : 00.90.00
           UUID : 96d08ec9:be7a1dde:6a768949:ae6babf0
  Creation Time : Fri Jan 23 14:27:38 2009
     Raid Level : raid5
  Used Dev Size : 973619200 (928.52 GiB 996.99 GB)
     Array Size : 2920857600 (2785.55 GiB 2990.96 GB)
   Raid Devices : 4
  Total Devices : 3
Preferred Minor : 2

    Update Time : Sat May 16 20:19:19 2009
          State : clean
 Active Devices : 3
Working Devices : 3
 Failed Devices : 1
  Spare Devices : 0
       Checksum : e4ea3b81 - correct
         Events : 18

         Layout : left-symmetric
     Chunk Size : 64K

      Number   Major   Minor   RaidDevice State
this     1       8       19        1      active sync   /dev/sdb3

   0     0       8        3        0      active sync   /dev/sda3
   1     1       8       19        1      active sync   /dev/sdb3
   2     2       8       35        2      active sync   /dev/sdc3
   3     3       0        0        3      faulty removed
/dev/sdc3:
          Magic : a92b4efc
        Version : 00.90.00
           UUID : 96d08ec9:be7a1dde:6a768949:ae6babf0
  Creation Time : Fri Jan 23 14:27:38 2009
     Raid Level : raid5
  Used Dev Size : 973619200 (928.52 GiB 996.99 GB)
     Array Size : 2920857600 (2785.55 GiB 2990.96 GB)
   Raid Devices : 4
  Total Devices : 3
Preferred Minor : 2

    Update Time : Sat May 16 20:19:19 2009
          State : clean
 Active Devices : 3
Working Devices : 3
 Failed Devices : 1
  Spare Devices : 0
       Checksum : e4ea3b93 - correct
         Events : 18

         Layout : left-symmetric
     Chunk Size : 64K

      Number   Major   Minor   RaidDevice State
this     2       8       35        2      active sync   /dev/sdc3

   0     0       8        3        0      active sync   /dev/sda3
   1     1       8       19        1      active sync   /dev/sdb3
   2     2       8       35        2      active sync   /dev/sdc3
   3     3       0        0        3      faulty removed
/dev/sdd3:
          Magic : a92b4efc
        Version : 00.90.00
           UUID : 96d08ec9:be7a1dde:6a768949:ae6babf0
  Creation Time : Fri Jan 23 14:27:38 2009
     Raid Level : raid5
  Used Dev Size : 973619200 (928.52 GiB 996.99 GB)
     Array Size : 2920857600 (2785.55 GiB 2990.96 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 2

    Update Time : Sat May 16 15:54:58 2009
          State : clean
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0
       Checksum : e4e9fde2 - correct
         Events : 14

         Layout : left-symmetric
     Chunk Size : 64K

      Number   Major   Minor   RaidDevice State
this     3       8       51        3      active sync   /dev/sdd3

   0     0       8        3        0      active sync   /dev/sda3
   1     1       8       19        1      active sync   /dev/sdb3
   2     2       8       35        2      active sync   /dev/sdc3
   3     3       8       51        3      active sync   /dev/sdd3

Mir ist aber auch nicht klar, warum der RaidDevice State unterschiedlich für die gleichen Platten angegeben ist...

Gruß
Peter

 

[PeterG]

wenn die neue mdadm version ärger macht, könnte man eine single platte einbauen und dort eine alte firmware aufspielen, die platten nach dem hochfahren einstecken und von hand mounten, und dann mal mdadm testen - wäre aber etwas "experimentell".

Dem Gedanken würde ich auch noch näher treten wollen. Ältere Firmware 0640 habe ich mir besorgt, die ist wohl vom Juni 2008 und müßte daher - hoffentlich - noch eine älteren mdadm-Version enthalten (2.6.7 ist von Ende Juni 2008). Was meinst Du mit "von Hand mounten"?

Gruß
Peter

 

[Supaman]

single platte mit alter FW + 4 platten mit neuerer firmware könnte beim booten ärger machen. deshalb erst booten, dann die platten nachträglich reinstecken, die 508 kann hat hotswap. dann musst du schauen, ob die erkannt wurden, ggf. von hand mounten und kannst schauen ob du mit mdadm was machen kannst.

aber wie gesagt: extern auslesen wäre sicherer, weil man dabei nichts überschreibt. eine 4-port controller karte kostet nicht viel.

 

[PeterG]

Hi,
ok, also mit einer Platte downgrade auf 0640 versucht (nur mit der einen Platte, die 4 Platten vom Raid ausgestöpselt). Leider das gleiche Problem wie nach dem Neustart, nach dem das Problem auftratt: Status-LED blinkt blau, nix passiert, DS nicht erreichbar, keine Reaktion auf Reset. Irgendwie scheint bei mir der Reset für Firmwarelöschung nicht zu funktionieren...Wieder hilft nur Steckerziehen, fährt aber danach nicht hoch, es bleibt beim blinkenden Blau. Also wieder Platte raus, erneut Steckerziehen, dann startet die DS. Platte rein, alte Firmware erneut aufgespielt, dann Neustart. Danach die 4 Raid-Platten rein. Mdadm-Version ist 2.6.5, die Fehlermeldung kommt nicht, aber es kann dennoch das Raid nicht wiederhergestellt werden:

mdadm: looking for devices for /dev/md2
mdadm: /dev/sda3 is identified as a member of /dev/md2, slot 0.
mdadm: /dev/sdb3 is identified as a member of /dev/md2, slot 1.
mdadm: /dev/sdc3 is identified as a member of /dev/md2, slot 2.
mdadm: /dev/sdd3 is identified as a member of /dev/md2, slot 3.
mdadm: added /dev/sdb3 to /dev/md2 as 1
mdadm: added /dev/sdc3 to /dev/md2 as 2
mdadm: added /dev/sdd3 to /dev/md2 as 3
mdadm: added /dev/sda3 to /dev/md2 as 0
mdadm: /dev/md2 assembled from 1 drive - not enough to start the array.

Dann ist wohl doch Start vom Scratch nötig, wenn ich das richtig sehe, oder?

Gruß
Peter

 

[itari]

Damit der mdadm --stop /dev/md2 geht, darf kein einziger Prozess mehr irgendwas mit dem /volume1 zu tun haben, da das /volume1 ja der mount-Point vom /dev/md2 ist.

Aber mal ne Frage, was willst denn eigentlich machen, wenn das Teil gestoppt worden ist?

Itari

PS. ok ... ich lass mal die Antwort noch ne Stunde hier stehen

 

[MeisterPro]

Ich probiere:

mdadm --stop /dev/md2

und bekomme:

mdadm: fail to stop array /dev/md2: Device or resource busy

habe schon alle Dienste die mir eingefallen sind angehalten, aber ich bekomme die Meldung nicht weg. Habe mich getraut den synoindexd zu killen, aber jetzt kann ich nicht einschätzen was ich noch "gefahrlos" stoppen kann.
Was könnte mir noch im Weg stehen?

 

[MeisterPro]

Jetzt ist die Reihenfolge verwürfelt - sorry.

Ich habe eine Platte die kaputt war - ist aus der RMA jetzt wieder da und er meldet Volume 1 sei "abgestürzt". Ich kann nicht reparieren und nicht erweitern.

Wie kann ich sicherstellen, dass kein einziger Prozess mehr irgendwas mit dem /volume1 zu tun hat?

 

[itari]

Scheib doch mal, welche Firmware du hast und welchen RAID-Typ du wiederherstellen willst und vor allem, was für eine DS/CS du hast

Itari

 

[MeisterPro]

ich habe die aktuelle Firmware.
...aber...
nach einem Reboot, bietet er mir plötzlich die RMA Platte an und baut das RAID wieder auf - so ich ich es vorher schon erwartet hatte. Wenn's jetzt durchläuft bin ich geretet.
Dane für die schnelle Reaktion!

 

[Evofan]

Hilfeeee

Hi Leute bin seit wenigen Tagen besitzer eines DS 409 + ausgestattet mit 4 1 Tera F1R Festplatten. zu meinem Problem habe etwa eine halbe woche lang meine Daten auf das Nas verschoben ca. 1.8 Tera. Als ich fertig war wollte ich mal den Smart Test mit den Festplatten durchspielen. Leider wurde eine gleich als Fehlerhaft (Anormal hiess es glaubs) bezeichnet. als ich weiter machte verschwand eine andere Plötzlich aus dem Volumen warum auch immer danach stürzte das Raid 5 auch ab. Habe jetzt gestern 4 1 Tera Samsunf F3 gekauft und jede Platte geklont mit Acronis True Image. jetzt zu dieser Anleitung welche ihr da rein gesetzt habe verstehe ich leider schon überhaupt nicht wo ich die ganzen kommandozeilen eingeben soll. Habe SSH un Telnet mal auf dem 409 Aktiviert und so ein Programm namens WinSCP Installiert, aber damit ging es überhaupt nicht. Ich hoffe ihr könnt das auch einem Laien was NAS angeht erklären, denn zu meinem Bedauern habe ich KEINE Kopie der ganzen Daten und würde somit um Jahre zurückgeschmissen:-(

 

[yasdfgr]

Zuerst musst du auf deiner DS (im Management) mal unter "Netzwerkdienste->Terminal" Telnet bzw. SSH aktivieren.

Sofern du noch WinXP hast gehst du in die Eingabeaufforderung und gibst telnet <IP-DS> (Beispiel: telnet 129.168.0.2)
Dann meldest du dich mit dem Benutzer root und deinem admin-Passwort an.

Jetzt kannst du die hier beschriebenen Befehle ausführen.
-----------------------------------------------------------------------

Eine weitere Möglichkeit ein "abgestürztes" RAID5 (mit 4 Platten) wieder zu beleben, wenn die anderen Methoden fehlschlagen:
Habe ich hier gefunden: http://ubuntuforums.org/archive/index.php/t-410136.html

Zunächst mittels

mdadm --examine /dev/sda3
mdadm --examine /dev/sdb3

usw...

für alle beteiligten Platten die Infos auslesen und irgendwo mal sichern.
Wichtig ist, dass man hieraus nun abliest, in welcher Reihenfolge die HDD's zum ursprünglichen RAID-Verbund gehören.
Das kann man an der slot-nummer sehen.

Nun sollte man das alte device stoppen und löschen.

mdadm --stop /dev/md2
mdadm --remove /dev/md2

Im nächsten Schritt wird das RAID mit der richtigen Plattenreihenfolge neu erzeugt.
Dieser Befehl zerstört die Daten auf den Platten nicht, auch wenn es so scheint!! (aber darauf achten nur Platten des RAIDs anzugeben)

In meinem Fall z.B. wurde das RAID5 ursprünglich mit der ersten Platte angefangen, dann mit Platte 2 auf RAID1 erweitert, dann mit Platte 4 auf RAID 5 erweitert, dann mit Platte 3 vergrößert.
Platte 3 ist komplett ausgefallen.
Später dann auch noch Platte 1 aus dem Verbund geworfen worden.

Nun erzeuge ich also ein neues RAID5 mit der alten Reihenfolge.
Wichtig ist eine Platte als missing anzugeben, selbst wenn sie vorhanden ist.
Das verhindert das ggfl. falsche resynching.

mdadm --create /dev/md2 --assume-clean --level=5 --raid-devices=4 /dev/sda1 /dev/sdb3 /dev/sdd3 missing

Die Sichheitsabfrage kann man mit yes bestätigen.
Das RAID wird erzeugt und auch gleich gestartet.

Dann versucht man das device zu mounten, z.B in volume1.

mount /dev/md2 /volume1

Hat das geklappt? Super, dann sollten alle Daten wieder da sein. Das überprüft man einfach mal.
Jetzt kann man die vierte Platte wieder reinschieben und das RAID wieder komplett reparieren (redundant machen).

Wenn das mounten fehl schlägt stimmt die Plattenreihenfolge beim Erzeugen des RAID evtl. nicht. Dann einfach nochmal von oben anfangen. (Vorsicht: nicht versuchen die Daten von Linux reparieren zu lassen!!!)