Ein Root-Server sollte immer mit einem RAID-System betrieben werden, um bei einem Festplattendefekt nicht einen kompletten Datenverlust und somit einen Systemausfall zu erleiden. Wenn ein Festplattendefekt auftritt, muss man unverzüglich mit seinem Provider einen Termin für den Hardwareaustausch vereinbaren. Üblicherweise wird der Provider "nur" die Festplatte austauschen. Diese wieder in das System einzubinden ist Aufgabe des Server-Betreibers.
Ob ein RAID-System noch mit allen Festplatten läuft, lässt sich am Einfachsten mit folgender Anweisung feststellen:
cat /proc/mdstat Personalities : [raid1] md1 : active raid1 sdb1[0] 1028096 blocks [2/1] [U_]
Anhand der Angabe [U_] bzw. [_U] kann man erkennen, dass im RAID-System eine Festplatte fehlt. Ein intaktes RAID-System erkennt man an der Ausgabe [UU]. Dadurch, dass nur die Partition sdb1 aufgelistet wird kann man auch erkennen, dass die Partition sda1 nicht mehr im RAID eingebunden ist.
Ist dies der Fall, sollte versucht werden die vermeintlich defekte Festplatte genauer zu analysieren, und evtl. erneut in das RAID-System aufzunehmen. Kommt man jedoch zu dem Ergebnis, dass die Festplatte defekt ist, muss mit dem Provider ein Hardwareaustausch vereinbart werden. Idealer Weise legt man einen definierten Zeitpunkt fest, weil nach dem Hardwaretausch die neue Festplatte wieder in das RAID-System eingebunden, und der Server in Betrieb genommen werden muss.
Alle nachfolgenden Schritte führen wir am Besten über die serielle Konsole des Servers aus, oder beobachten zu mindestens über die serielle Konsole die Boot-Vorgänge. Dadurch hat man einen detaillierteren Einblick, falls etwas schief gehen sollte.
Beim Provider 1&1 wird nach einem Festplattenaustausch der Server im so genannten Rescue-Modus gestartet. Dies ist ein abgespecktes Not-System unabhängig von den verbauten Festplatten, und kann solange der Server keinen anderen Defekt aufweist auf jeden Fall immer gestartet werden.
Nach dem Anmelden über das Rescue-System sehen wir uns mit dem Befehl fdisk -l die Partitionstabellen beider Festplatten an. Dabei erkennen wir, dass auf der "alten" Festplatte (in unserem Fall sdb) 4 Partitionen angelegt sind, und die "neue" Festplatte (in unserem Fall sda) noch keine Partitionierung aufweist. Da für ein RAID-System beide Festplatten gleich Partitioniert sein müssen, übernehmen wir mit folgendem Befehl die Partitionstabelle von der Festplatte sdb auf sda:
sfdisk -d /dev/sdb | sfdisk /dev/sda
Anschließend sollte ein erneuter Aufruf des Befehls fdisk -l beide Festplatten mit identischen Partitionstabellen zeigen.
In unserem Fall war es (leider) so, dass die sda-Festplatte betroffen war, und auf dieser der Bootloader hinterlegt ist. Da dieser nicht mehr vorhanden ist, kann der Server nicht mehr von der Festplatte booten. Wir müssen also zuerst den Bootloader auf die Festplatte sda schreiben, um das System wieder normal hochfahren zu können. Dazu hängen wir alle 4 Partitionen in das Rescue-System ein, und wechseln in eine chroot-Umgebung:
mount /dev/md1 /mnt mount /dev/md5 /mnt/usr mount /dev/md6 /mnt/var mount /dev/md7 /mnt/home chroot /mnt
Auf unserem SUSE-Linux wird GRUB als Bootloader verwendet. Um den Bootloader auf die sda-Festplatte zu schreiben nutzen wir folgenden Befehl:
grub-install /dev/sda
Nun haben wir alle Vorkehrungen getroffen, um das System wieder normal starten, und das RAID-System synchronisieren zu können. Hierzu müssen wir die chroot-Umgebung beenden, und die Partitionen aus dem Rescue-System aushängen:
exit umount /dev/md1 umount /dev/md5 umount /dev/md6 umount /dev/md7
Im 1&1 Kundenmenü stellen wir ein, dass beim nächsten booten wieder das "normale Betriebssystem" und kein Rescue-System verwendet werden soll. Den Neustart selbst führen wir jedoch nicht über das Kundenmenü, sondern in der Shell des Rescue-Systems aus:
reboot
Wenn alles gut gegangen ist, startet der Root-Server nun in seinem normalen Betriebssystem und sollte wieder wie gewohnt voll einsatzfähig sein. Allerdings läuft das RAID-System immer noch nur auf der sdb-Festplatte, was wir mit dem Befehl cat /proc/mdstat nachprüfen können.
Unsere letzte Aufgabe besteht also darin, die Partitionen der sda-Festplatte wieder in das RAID-System einzubinden:
mdadm /dev/md1 -a /dev/sda1 mdadm /dev/md5 -a /dev/sda5 mdadm /dev/md6 -a /dev/sda6 mdadm /dev/md7 -a /dev/sda7
Dies kann je nach Festplattengröße einige Stunden in Anspruch nehmen. Während dieser Zeit ist der Server voll funktionsfähig, und kann wie gewohnt verwendet werden. Der Status der Synchronisierung kann über watch cat /proc/mdstat fortlaufend beobachtet werden. Ist die Synchronisierung vollständig abgeschlossen, ist das RAID-System wieder komplett, und es besteht die gleiche Ausfallsicherheit wie vor dem Festplattentausch.
Beim in Betrieb nehmen des Servers nach dem Festplattentausch, sowie für die Erzeugung dieser Dokumentation, haben mir folgenden Seiten maßgeblich geholfen:
http://hilfe-center.1und1.de/server/root_server/rescue_und_recovery/2.html
http://wiki.hetzner.de/index.php/Austausch_einer_defekten_Festplatte_im_Software-RAID
http://wiki.ubuntuusers.de/GRUB#Bootloader-wiederherstellen