Posts Tagged ‘mdadm’

Ein ungewollter Neuanfang

Thursday, April 16th, 2009

Eigentlich bin ich ja ein geduldiger Mensch und eigentlich nehm ich die meisten Dinge gar nicht so schwer – anders als die Leute hier im Zug heute morgen, die schon wegen einer Verspaetung von 10 Minuten wegen Bauarbeiten am Gleis (vor Einfahrt) ein Theater machen, als ginge es um ihre Existenz. Lieber puenktlich im Grab dank kaputten Gleisen? Naja… als dann um 5:30 von einem Fahrgast protestiert “Die sollen das doch in der Nacht machen!”, hab ich dann entgueltig weggehoert und in Ruhe auf den Zug gewartet…
Aber ich war bei meiner eigenen Geduld. Die meisten Dinge nehm ich leicht und es dauert wirklich eine ganze Weile, bis mich etwas so sehr nervt , dass ich an die Decke gehe. Gestern hat mich allerdings der ganze Abend so sehr genervt, dass ich auch 200m Deckenhoehe muehelos ueberbrueckt haette. Warum? Das ist verhaeltnismaessig einfach, wenn auch eine so bloede Verkettung ungluecklicher Umstaende und Dummheiten, dass ich fast nicht drueber zu sprechen wage – in der Angst, alleine darueber nachzudenken wuerde mich durchs Zugdach befoerdern.

Am Dienstag Morgen wachte ich vollkommen zu spaet (5:30, wie oben zu sehen bin ich da oft schon am Bahnhof) auf und beschloss daraufhin einen Zug spaeter zu nehmen und mich nicht noch abzuhetzen um in den verbleibenden 15 Minuten moeglicherweise in der Eile nur halb bekleidet am Bahnhof zu erscheinen. Ich nahm mein Netbook zur Hand – welches auf dem Bett liegt fuer eben solche Fälle und das allmorgentliche Checkup – und las meine Mail. Eine Systembenachrichtigung fiel mir besonders ins Auge, sie kam von meinem Fileserver und las sich etwa so:

Date: Tue, 14 Apr 2009 04:12:27 +0200
From: mdadm monitoring <root@utena>
To: root@utena
Subject: Fail event on /dev/md0:utena   

A Fail event had been detected on md device /dev/md0.
It could be related to component device /dev/sdc2.

P.S. The /proc/mdstat file currently contains the following:
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sda2[0] sdc2[3](F) sdb2[1]
      781128320 blocks level 5, 64k chunk, algorithm 2 [3/2] [UU_]
unused devices: <none>

Naja… eine Platte weg im RAID 5? Dafuer isset ja da, nich? Ich hatte eigentlich nicht vor gehabt, gerade Festplatten zu kaufen, aber gut.
Bei dem System handelt es sich uebrigens um meinen Fileserver, welcher so ziemlich alle Daten meiner Maschinen sichert und auch Daten vorhaelt, die aus alten Sicherungen behalten werden sollten. Als ich mich dann auf der Maschine einloggen wollte, um nachzusehen, was denn passiert war, begruesste mich selbige anstatt mit einem Prompt mit einem einsilbigen “Input/Output Error” und ueberliess mich meinem Informationshunger. Ein kurzer Gang in die Kueche verriet, dass die Email nicht dem aktuellen Stand der Dinge entsprach. /proc/mdstat sah naemlich eher so aus:

Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sda2[0] sdc2[3](S) sdb2[1](S)
      781128320 blocks level 5, 64k chunk, algorithm 2 [3/1] [U__]
unused devices: <none>

Und warum auch immer die ehemals ausgefallene Platte dort als Spare auftauchte (und eben eine weitere), es konnte nichts gutes heissen. Die Tatsache alleine, dass laut Systemprotokoll die Platten in einem Abstand von ca 60 Sekunden aus dem Array flogen, machte mich skeptisch. Gleichsam war ich allerdings sicher, dass ich nichts haette tun koennen. Nach einem spontanen Plattentausch um 4:12 haette es bestimmt keinen kompletten rebuild in 60 Sekunden gegeben. Ich fuhr also zur arbeit, in der Sicherheit, es sei nur ein Kabel verrutscht oder soetwas banales.

Eine Abentliche Inspektion der Platten warf ein anderes Bild auf den Ablauf. Es schein als seien tatsaechlich 2 HDDs innerhalb einer Minute ueber die Wupper gegangen. Trotzdem die Wupper ja relativ schmal ist und so flach, dass selbst Elefanten in ihr schwimmen koennen, scheiterten saemtliche Versuche, Teile der Daten wiederherzustellen. Aufgrund der Tatsache, dass es 1:00 Uhr war, bis ich das feststellte und um 5:00 der Wecker wieder Laerm machen wuerde, vertagte ich weitere Versuche auf gestern – was vielleicht ein Fehler war.

Nach der Arbeit schritt ich gestern – bewaffnet mit einem USB-Stick – an meinen Arbeitsrechner in dem sich 5 Platten mit diversen Daten befinden. Meine Absicht war, den USB-Stick mit einer grml-Installation auszustatten, um den Fileserver davon starten zu koennen. Ich steckte den USB-Stick an und wollte ihn nullen, um bootsektor und co von eventuellen Debian-Installer Resten zu reinigen. Nullen tat ich stattdessen eine der eingebauten Festplatten, da ich das falsche Device angab. Dies merkte ich nach etwa 2GB geschriebenen Nullen auf ein Crypt-Volume -> Daten im Po. Das Elend nahm jedoch kein Ende… nach Schreiben des grml-Mediums auf den USB-Stick installierte ich syslinux in das falsche Volume – ebenfalls ein Crypt-Volume – was die Systemplatte des Arbeitsrechners und mein Homedir mit vielen gesammelten Werken – zumindest Datenmaessig – ins Jenseits befoerderte. Ich wess, dass syslinux normalerweise prueft, ob sich auf den angegebenen Device um ein FAT-Dateisystem handelt oder nicht – ich wuerde gerne wissen, was hier schief gegangen ist. Jeder halbwegs vernuenftige Mensch wird mich jetzt fragen wollen “Warum spielst du nicht einfach die Backups zurueck?” – ganz einfach: Die lagen auf dem Fileserver zu dessen Rettung ich zu eilen aufgebrochen war.

Wieder angekommen in der Kueche, wo mein Netbook per SSH auf dem inzwischen auf wunderbare Weise bootfaehigen grml-USB-Stick im Fileserver herumfrickelte, setzte ich mich hin um zu retten was zu retten war.I ch verbrachte so einige Stunden und wollte nur kurz aufstehen um im anderen Raum etwas zu holen. Dabei fiel mir das Netbook aus der Hand, ich griff nach, packte es auch – zerdrueckte dabei allerdings gekonnt mittig das Display.

Etwas zweifelnd ob da eine gute Idee sei, ersetzte ich das Netbook durch mein Notebook und arbeitete weiter. Zumindets konnte ich die Konfiguration meiner Backups retten und kann so ab heute auf einer anderen Maschine Datensicherungen fahren. Der Rest der Daten – ein gut gepflegtes Archiv elektronischer Netlabel-Musik der letzten Jahre beispielsweise, von der so manches nicht mehr zu bekommen ist – sind allerdings verloren. Gegen Ende der Arbeiten starb in meinem Arbeitsrechner dann allerdings auch noch eine der verbleibenden Platten, auf die ich in der Panik die Fragmente rettete, die noch zu retten waren – und die ich zum Glueck nicht nur auf eine Platte kopiert habe.

Waehrend der Rettung stellte ich allerdings noch fest, dass das Mainboard im Fileserver ebenfalls eine Macke am S-ATA Controller hatte. Diesem flogen naemlich regelmaessig 2 Kanaele ab, was ich ersteinmal fuer den Datenverlust auf den Platten verantwortlich machte und das bereitgelegte Ersatzmainboard (war fuer Strompar-Zewcke vorgesehen) einbaute. Es stellte sich allerdings heraus, dass Mainboard und Platten – ich darf hinzufuegen alle DREI Platten aus dem Array – eine Meise hatten. Vermutlich flog bloss die letzte nicht, weil  dem mdadm das bei einem eh nicht mehr funktionstuechtigen array recht egal ist und kein Datenverkehr mehr stattfindet, der ihn darauf aufmerksam machen koennte. Ich bilanziere also:

  • 3x 400GB Festplatten sind ausgefallen
  • 400 GB an Daten wurden durch Trantuetigkeit vernichtet
  • ein Mainboard segnete das Zeitliche
  • ein Netbook wurde durch rohe Gewalt zerstoert

Rechnet man das auf einen Abend um, so ergibt sich ein Bild des Schreckens, etwa 1000 Euro an Hardware an einem Abend zerlegt, von den Daten mal nicht gesprochen. Das sind fast 2 Monatsgehälter fuer einen Azubi. Da auch viel viel Zeit und Arbeit in den verlorenen Daten steckt, moechte ich allerdings so genau gar nicht wissen, was ich im Endeffekt durch die Aktion verloren habe. Was mit bleibt ist, zu hoffen, dass mir soetwas in Zukunft nicht mehr passiert.

Es gruesst ein niedergeschlagener Sternensucher