Raid5 wiederherstellen

[nichts]

Hallo Leute,
habe leider einen dummen Fehler gemacht.
Mein Debian Etch hostet ein Software Raid5 mit 6 Festplatten.
Bedauerlicherweise ist mir eine davon aufgrund von Hardwareschäden abgeraucht. Das Raid lief also problemlos mit 5 Festplatten weiter. Im Raidverbund befinden sich:
/dev/sda1
/dev/sdb1
/dev/sdc1
/dev/sdd1
/dev/sde1
/dev/sdf1

Da ich Mehrere Controller verwende und die Festplatten alle vom gleichen Typ sind war es für mich schwierig festzustellen, welche Platte nun wirklich kaputt ist. Laut /proc/mdstat hatte /dev/sdc einen Knacks weg. Aber welcher Physikalische Port ist das? Ich war leider zu voreilig und habe mich für den falschen entschieden.
*klack* Und ich habe /dev/sda abgestöpselt (im laufenden Betrieb, sind SATA Platten im Controller AHCI Modus).
Kurz drauf markierte logischerweise Debian die Platte /dev/sda im Raid mit einem dicken F. Am cleversten erschien es mir nach diesem Fehler das Raid aus dem Dateisystem auszuhängen, damit darauf nicht mehr gearbeitet werden kann. Dabei kam es zu fehlern und ich startete das System neu. Bevor ich das System wieder booten lies stellte ich sicher, dass /dev/sda wieder an seinem Port hängt und habe dann /dev/sdc entfernt und den Rechner in der Hofnung booten lassen, dass er die 5 funktionsfähigen Platten wieder erkennt.
Das war leider ganz und gar nicht der Fall. Debian hat die Laufwerksbuchstaben "aufrücken" lassen, warum eigentlich? Jedenfalls gab es kein "fehlendes" /dev/sdc, sondern alle laufwerke bis /dev/sde und /dev/sdf fehlte...
Folglich konnte das Raid seine Platten nicht mehr richtig zuordnen und verweigerte immernoch den Dienst.

Ich besitze nun eine angemessen große Ersatzplatte, die ich wieder an den Port /dev/sdc hängen könnte.
Dadurch müssten die Buchstaben wieder in die richtige Reihenfolge rücken.
Die Frage ist habe ich noch chancen das als crashed markierte Raid5 Array wieder zum Leben zu erwecken?
Wie sollte ich am besten vorgehen?
Ich habe wohl nur einen Versuch, denn an Backupplatz für Abbilder der HDDs bräuchte ich dann 6TB und soviel hab ich verständlicherweise nicht zur Verfügung.

Habe im Netz mal aufgeschnappt das folgendes helfen könnte:
mdadm --assemble --force /dev/md0 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1

Können mir durch --force und eventuelles Überschreiben des Superblocks weitere Probleme entstehen?
Wäre es sinnvoll die zuvor ausgestiegene und nun durch eine neue ersetzte Festplatte beim Assemble Befehl wegzulassen? Quasi mit folgendem Befehl:
mdadm --assemble --force /dev/md0 /dev/sda1 /dev/sdb1 missing /dev/sdd1 /dev/sde1 /dev/sdf1

Ich hoffe auf eure Hilfe

Grüße
Dennis

[Natureshadow]

Hallo Dennis,

Linux (bzw. udev) vergibt Gerätenamen für SCSI-Geräte dynamisch. Um damit sinnvoll zu arbeiten, müsstest du also entweder Labels für deine Software-RAID-Partitionen benutzen der deren UUIDs. Noch besser wären allerdings ein paar handfeste udev-Regeln.

Wieso hast du die "falsche" Platte nicht einfach wieder angeschlossen? Ein RAID 5 sollte das verkraften ...

Grüße,
Nik

[nichts]

Hallo,

Um damit sinnvoll zu arbeiten, müsstest du also entweder Labels für deine Software-RAID-Partitionen benutzen der deren UUIDs.

Hmm ich bin nicht sicher wie du das meinst. Auf der "Ebene" habe ich mich bisher leider auch kaum eingearbeitet. Hast du entsprechende Literaturverweise für mich?

Wieso hast du die "falsche" Platte nicht einfach wieder angeschlossen? Ein RAID 5 sollte das verkraften ...

Habe ich! Wie gesagt nachdem ich die "falsche" Platte abgeklemmt habe, fehlten ja 2 Festplatten... Die "fälschlicherweise" abgeklemmte wurde als Faulty markiert und der Status blieb auch nachdem ich sie wieder angesteckt hatte. Daher schien es mir am klügsten neu zu starten. Nunja und nun steht die fälschlicherweise abgeklemmte Platte nichtmal mehr in der Liste der verwendeten Devices wenn ich mir /proc/mdstat ansehe.

Hast du einen heißen Tip für mich, wie ich das Raid wieder hinbekommen könnte?

Grüße
Dennis

[Natureshadow]

Nö, da kann ich dir nun akut auch nichts zu sagen was nicht mit ziemlicher Sicherheit zu Datenverlust führen würde ...

Bzgl der Gerätenamen: http://www.cyberciti.biz/tips/linux-ass ... vices.html

-nik

[nichts]

Habe mein Problem erfolgeich gelöst.
Hier mal fürs Protokoll und Leute die evtl. ein ähnliches Problem haben:

Da die Plattenreihenfolge durcheinander war war es notwendig, die entfernte und kaputte Festplatte zunächst durch eine neue zu ersetzen. Dadurch stimmte die Reihenfolge der Laufwerke wieder.Nach einem Systemstart erhielt ich dann folgenden Status:

Code: Alles auswählen

mdadm --detail /dev/md0
/dev/md0:
        Version : 00.90.03
  Creation Time : Tue Nov 18 12:29:21 2008
     Raid Level : raid5
    Device Size : 976759936 (931.51 GiB 1000.20 GB)
   Raid Devices : 6
  Total Devices : 4
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Thu Nov 27 23:36:42 2008
          State : active, degraded, Not Started
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 64K

           UUID : xXxXxXxXxXxXxXxXxXxXxXxXxX
         Events : 0.150914

    Number   Major   Minor   RaidDevice State
       0       0        0        0      removed
       1       8       17        1      active sync   /dev/sdb1
       2       0        0        2      removed
       3       8       49        3      active sync   /dev/sdd1
       4       8       65        4      active sync   /dev/sde1
       5       8       81        5      active sync   /dev/sdf1

Folglich hat er /dev/sda1 durch mein versehentliches abstöpseln einfach entfernt. Ein simples mdadm --manage --add /dev/md0 /dev/sda1 brachte den erhofften Erfolg und wurde quittiert mit "mdadm: re-added /dev/sda1".

Mit mdadm --detail /dev/md0 erhielt ich dann folgende Auflistung:

Code: Alles auswählen

    Number   Major   Minor   RaidDevice State
       0       8        1        0      active sync   /dev/sda1
       1       8       17        1      active sync   /dev/sdb1
       2       0        0        2      removed
       3       8       49        3      active sync   /dev/sdd1
       4       8       65        4      active sync   /dev/sde1
       5       8       81        5      active sync   /dev/sdf1

Es hat also offenbar wirklich nicht geschadet. Die platten werden immernoch als "sync" angezeigt, super! Lediglich den Status "State : active, degraded, Not Started" musste ich noch wegbekommen. Das war relativ einfach mit "mdadm --manage --run /dev/md0" möglich.
Der Status steht nun auf "State : clean, degraded" und cat /proc/mdstat sieht auch gut aus:

Code: Alles auswählen

cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid5 sda1[0] sdb1[1] sdf1[5] sde1[4] sdd1[3]
      4883799680 blocks level 5, 64k chunk, algorithm 2 [6/5] [UU_UUU]

Schätze nun kann ich die fehlende Platte durch die neue ersetzen und ein Rebuild wird ordnungsgemäß durchgeführt. Bei 6x 1TB könnte das jedoch etwas dauern. Ob alles geklappt hat teile ich euch noch mit.

Grüße
Dennis

[nichts]

So ich kann das Vorgehen als erfolgreich bestätigen. Grade läuft ein Rebuild, ich konnte allerdings schon per Samba auf die Daten zugreifen und mich von deren Unversehrtheit überzeugen.

Nun werde ich mich erstmal in udev einlesen, damit mir soetwas nicht nochmal passiert. Danke für die Hilfe!

[error]

wie lange hat dein rebuild gedauert, wenn du das noch in erinnerung hast.
edit: meine 4x1TB USB lösung macht grad einen resync durch, der dauert nach berechnung 33 stunden bei 8 MB / sek.