Heute Morgen geriet ich dann doch etwas in Panik! Mein Postfach war voller Fehlermeldungen vom RAID-System und von S.M.A.R.T. Demnach waren zwei Festplatten ausgefallen. S.M.A.R.T. war der Meinung, /dev/sdb und /dev/sdc seien zwar noch da, könnten aber nicht geöffnet werden oder seien keine Laufwerke, die S.M.A.R.T.-Daten zur Verfügung stellten. Und MDADM, das RAID-System, war der Meinung, die Laufwerke hätten ein Problem und setzte mal eben das RAID herab. Da es ja jetzt aber zwei Platten sind, ging am RAID erst mal gar nichts mehr!

Eine kurze Abfrage der /proc/mdstat ergab leider auch nichts brauchbares, da SDb1 und SDC1 einfach nur als defekt markiert wurden. Nun hätte ich viele der Reparaturversuche sofort machen können, tat dies aber nicht. Ich hatte nämlich vorher, als ich mich noch in Linux eingelesen hatte, in einem Forum gesehen, dass so ein Problem, ganz wie bei Windows, bei einem Reboot wieder verschwindet. Gesagt, getan, und nicht gestartet. 🙁 Der Server fuhr einfach nicht mehr hoch. Und da ja nun kein Bildschirm und keine Tastatur angeschlossen ist, wusste ich auch nicht, was denn nun vor sich geht. Also habe ich den Server abgebaut und zu mir an meinen Schreibtisch geholt.

Erinnert ihr euch, dass ich relativ kurz nach der Installation BRLTTY wieder deinstalliert hatte, weil es ja nicht benötigt würde? Ganz schlechte Idee, wie sich jetzt herausstellt. 🙂 Aber, halb so wild, ich habe es ja wieder installieren können, für so was einfaches reichte mein Sehrest noch. Aber nur so zur Info, lieber nicht deinstallieren. 🙂

Startversuch

Das System bleibt mitten im Bootvorgang stehen und meldet einen Fehler. Ich habe die Fehlermeldung nicht mehr genau im Kopf, aber in Etwa sah es so aus:

FSCK died with exit code 8

Oder so etwas ähnliches. Und dann noch ein englischer Text, dass nun eine Maintenance Shell gestartet würde, damit man das Problem beheben könne. Und wenn man dies getan hätte, könne man ja Ctrl+D drücken, um normal weiterzubooten. Gut, ich habe das ignoriert und habe gleich Ctrl+D gedrückt.

RAID analysieren

Wenn ich mir nun die /proc/mdstat angucke, steht das RAID MD0 dort als inactive, also es ist nicht gestartet. Alle Platten stehen dort als Spare, also hinter jeder Bezeichnung der Platten steht ein (S).

Manuelles Starten des RAID

Bevor man nun irgendetwas tut, muss das RAID erst mal gestoppt werden:

sudo mdadm --stop /dev/md0

Gibt man folgenden Befehl ein,

sudo mdadm --assemble /dev/md0

müsste das RAID sich selbst wieder zusammensetzen und starten. In meinem Falle ging das aber nicht. Also habe ich den Befehl noch etwas anders eingegeben:

sudo mdadm --assemble --verbose /dev/md0

Dieser Befehl gibt eine Menge Informationen aus, ob etwas klappt, und wenn nicht, warum nicht. Allerdings hatte ich diese Befehle alle angewendet, als mein Server hier am Schreibtisch Stand und keine Netzverbindung hatte. Ich habe daher die Ausgaben nicht gespeichert und gebe die Daten aus dem Kopf wieder.

Bei den Festplatten /dev/sdb1 und /dev/sdc1 bekam ich die Fehlermeldung "has no Superblock". Der Superblock ist der Bereich, indem das RAID eine Menge an Informationen über das RAID selbst und seine beteiligten Festplatten ablegt.

Das selbständige zusammensetzen hat also nicht geklappt, dann also per Hand. Und, bevor ein Array wieder gestartet und zusammengesetzt werden kann, muss es immer erst gestoppt werden. Also setze ich das RAID so zusammen:

sudo mdadm --assemble /dev/md0 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1

Auch kein Glück:

MDADM: Assemby of /dev/md0 from 3 drives, not enough to start the array.

Aus dem Kopf geschrieben, die Formulierung könnte geringfügig anders sein.

Reparieren des RAID

Zunächst überprüfe ich erst mal, ob die Festplatten wirklich nicht kaputt sind. Ich mache keine außerordentlich ausführliche Prüfung, sondern ich checke einfach nur mal, ob die durch S.M.A.R.T. gemeldeten Probleme noch da sind:

sudo smartctl -a /dev/sdb

Und das mache ich natürlich mit allen als defekt gemeldeten Platten. Die Ausgabe ist sehr umfangreich, zumeist reicht aber, die ersten paar Werte zu sehen, und ob sie in Ordnung sind. In meinem Fall sind beide Platten in Ordnung, weiß der Geier, warum die rumgezickt haben.

Wie auch immer, wo ja nun klar ist, dass /dev/sdb1 und /dev/sdc1 in Ordnung sind, können wir das RAID wieder reparieren. Und zwar teile ich MDADM mit, dass die Platten in Ordnung sind und er sie starten soll, auch wenn er meint, er würde Fehler finden.

sudo mdadm --assemble --force /dev/md0

Nun startet zwar das RAID, aber nur mit 4 statt 5 Platten. Aber es startet. Nun gucke ich mit cat /proc/mdstat mal rein, was das Problem ist, und /dev/sdb1 ist aus irgendwelchen Gründen nicht hinzugefügt worden. Es ist also gar nicht mehr im RAID-Verbund. OK, dann müssen wir diese Platte wieder hinzufügen:

sudo mdadm --add /dev/md0 /dev/sdb1

Die Platte wird dem RAID hinzugefügt und die Rekonstruktion des RAID beginnt. Dies kann einige Zeit dauern, in meinem Fall so um die 5 Stunden.

Fazit

Das Schöne ist, man kann den Rechner jetzt einfach abschalten, zurück in seine dunkle Ecke tragen und dort wieder in Betrieb nehmen. Der Server startet wieder normal und beginnt sofort die Rekonstruktion.

Ich habe von meinen Daten ein Backup. Schlimmstenfalls wäre mir Arbeit von 3 oder 4 Tagen verlorengegangen, damit hätte ich leben können. Ich bin aber dennoch erstaunt, wie robust das RAID-System ist. Zwar war wieder eine Menge Lesen angesagt, aber letztlich kann man sich selbst aus so einer Situation wieder retten.

Andererseits habe ich nicht die geringste Ahnung, was eigentlich passiert ist. Wieso waren die beiden Laufwerke auf einmal nicht mehr ansprechbar? Da ich die Ursache nicht kenne, und auch irgendwie nicht rausfinde, bleibt mir nur zu hoffen, dass es so schnell nicht wieder passiert. Und falls doch, immer schön das Backup aktuell halten!