Recovering von Festplatten im Server - Linux ist super

Heute ist mir etwas leicht blödes passiert, doch dank der Flexibilität und Robustheit meines Lieblingsbetriebssystems habe ich es doch recht gut in den Griff bekommen.

Ausgangsituation:

• Linux System mit VMWare Server 2 (und etlichen laufenden virtuellen Maschinen darin).
• Einige Datenfestplatten welche per LUKS verschlüsselt sind.
• Ein defekter Systemlüfter in selbigem Server

Da die virtuellen Maschinen meiner Meinung nach kritische Prozesse sind (und ich sowieso zu faul zum suspenden/herunterfahren derselbigen bin), schied das rebooten des servers von vornherein aus. Es ist sowieso nur der Gehäuselüfter zu tauschen, also kann man den auch im laufenden Betrieb tauschen. Gesagt getan, Rechner aufgeschraubt, Lüfter abgezogen und... irgendwie doof an einem SATA Stromkabel hängen geblieben. Folge: Die Platte war kurz aus und sofort wieder da. Das reichte jedoch dem Kernel schon um sie mit tausenden Meldung in den Offline Modus zu verfrachten: "sd 3:0:0:0: rejecting I/O to offline device".

Da rutscht einem das Herz erstmal total in die Hose und man ist erstmal ein wenig ratlos. Eine Festplatte die eigentlich wieder tadellos da ist, dem Kernel bekannt ist und somit funktionieren müsste.

Erster Anlauf: "rescan-scsi-bus" was jedoch nichts brachte, da die Festplatte ja bereits wieder aktiv ist, nur weiss davon ja der filesystem Treiber nichts. Schlimmer wurde es mit "lvmdiskscan", das war vollends verwirrt.

/dev/block/253:1: read failed after 0 of 4096 at 203927453696: Input/output error

/dev/block/253:1: read failed after 0 of 4096 at 203927556096: Input/output error

/dev/block/253:1: read failed after 0 of 4096 at 0: Input/output error

/dev/block/253:1: read failed after 0 of 4096 at 4096: Input/output error

Was nun tun? Die Platte muss aus dem System raus und wieder rein. Also erst unmounten... halt, vorher den nfsd daemon beenden, da sie noch in Verwendung ist. Anschliessend funktionierte zum Glück "cryptsetup remove data2", die Platte wird also nun vom System nicht mehr verwendet, ist demselbigen jedoch immernoch bekannt.

Nun muss man ein bisschen tief in den Unterbau eingreifen. Doch zum Glück ist ja bei Linux fast alles auch im Dateisystem steuerbar (Unixgrundsatz Nummer eins: "Everything is a file"). Die SATA Platten laufen im SCSI Subsystem, weshalb man diese auch per "/sys/bus/scsi/*" steuern kann.

Zuerst identifizieren wir das fehlerhafte device, aus obiger Meldung erfahren wir, dass es "3:0:0:0" ist und entfernt wird es durch folgenden Befehl:

root@valhal# echo x > /sys/bus/scsi/devices/3\:0\:0\:0/delete

Damit ist die Platte beim Kernel offiziell abgemeldet und wir können sie durch einen normalen SCSI rescan wieder einhängen, sollte dies wider Erwarten nicht klappen, kann man auch per sys filesystem auf dem controller direkt einen rescan anfordern:

root@valhal# echo "- - -" > /sys/class/scsi_host/host3/scan

Damit wird der Bus an Controller 3 neu gescanned.

Nachdem ich per "cryptsetup luksOpen" die Platte wieder beim device mapper angemeldet, anschliessend gemounted und den nfsd wieder gestartet habe, war eigentlich alles getan. Das System läuft wieder, alle Datenspeicher sind erreichbar und der Lüfter ist auch eingebaut.

Mit einem anderen Betriebssystem wäre die Aktion sicher nicht so glimpflich abgegangen bzw. hätte mindestens einen reboot erfordert.