Sex mit kleinen gelben Haftetiketten

Nach dem Ausfall der letzten garantiegetauschten Platte hatte ich eine ganze Weile lang Ruhe in meinem Daten-RAID.

Jetzt habe ich seit gestern schon drei Meldungen vom RAID-Controller bekommen, daß eine der Systemplatten wieder fehlerhafte Sektoren hustet. Die lief in den letzten knapp zwei Jahren permanent mit 256 defekten Sektoren einwandfrei. Seit gestern hat sich diese Zahl auf knapp 296 erhöht. Werde das wohl im Auge behalten müssen.

Glücklicherweise wartet in meinem Array eine HotSpare-Scheibe schon darauf, den Ausfall der Systemplatte zu kompensieren – ich hoffe, daß das glatt geht. Bei einem anderen Plattenausfall hat der Treiber eine seltsame Exception geschmissen und den Rechner rebootet. Blöderweise hat das RAID-Controller-BIOS den Systemstart mit einer “RAID STATE CRITICAL”-Warnung aufgehalten…

Naja, jedenfalls sind die Systemplatten nicht im HotSwap-Rahmen, von daher wird die karp0tte erst ausgebaut, wenn die Hütte wirklich brennt – oder sich die Garantie dem Ende neigt. Aber das hat immer noch knapp 5 Jahre Zeit. Bis dahin schmiert die ganz sicher noch ab, da habe ich keine Bedenken…

Mei, schkrich the fucking Crysis!

Vor einigen Wochen hatte ich ja zunächst mal die Idee, mein Daten-RAID zu vergrößern. Da der RIAD-Controller außerdem noch bei zwei Platten (teilweise massig) fehlerhafte Sektoren gemeldet hat, bin ich schnell zu K&M Eletronik hier vor Ort in München gewandert und habe zwei identische Platten der Serie SAMSUNG HE103UJ erworben und die defekten ausgetauscht.

DAS hätte ich mal besser bleiben lassen, denn mitten im Array-Rebuilding fiel die erste neue Platte aus. Und ich hatte eine 20h-Schicht am Rechner, während der ich ca. 80% der Daten retten konnte. War leider von Sonntag Abend bis Montag Nachmittag, also hatte ich einen ganzen Tag Verdienstausfall.

Die Katastrophenplatte hat mir K&M glücklicherweise anstandslos vor Ort ausgetauscht, ich musste lediglich ein paar Tage warten, bis die Platte den Weg vom Zentrallager in den Laden geschafft hatte. Die beiden “bißchen kaputten” Platten habe ich zum deutschen Samsung-Partner eingeschickt und vorgestern nach ca. 2 Wochen Bearbeitungszeit wiederbekommen. Juhu.

Ab in die Wechselrahmen und ran an den Controller. Schaden macht Klug, dachte ich mir, und habe die beiden Platten gleich mal einem Burn-In unterzogen. Wie übrigens auch schon der K&M-Austauschplatte.

UND WAS IS?!?!?

Der Controller hat die eine Scheißplatte gleich zweimal wegen Fehler gekickt. Das erste Mal gestern Abend um 23:30 (danke “audible alarm”, ich hatte schon gepennt), das zweite Mal laut Logfile und tausend Error-Mails um 4 Uhr nochwas. Zum Glück hatte ich den nervtötenden Piepsealarm gestern noch abgeschaltet.

Gerade läuft badblocks das dritte Mal an, aber selbst wenn es tatsächlich durchlaufen sollte, habe ich jetzt schon erhebliche Hemmungen, der Platte jemals irgendwelche Daten anzuvertrauen. Leider liefert kein Log brauchbare Fehlermeldungen, der RAID-Controller meldet nur einen “I/O error”, aber nix mit fehlerhaften Sektoren oder sowas. Also tippe ich auf den Plattencontroller.

Falls der dritte Lauf fehlschlägt, werde ich die Platte nochmal an einem anderen Port testen, aber ich vermute schon jetzt, daß ich die Platte kommende Woche mit Anlauf zurück zu EDC nach Kelsterbach treten werde. Und nochmal drei Wochen warte, bis der Garantietausch endlich abgeschlossen ist…

Der Controller loggt übrigens wie folgt:

Feb 26 04:35:02 capoeira kernel: [1962364.950527] rr232x:[0,2] completion error, flags=84
Feb 26 04:35:02 capoeira kernel: [1962364.950530]
Feb 26 04:35:02 capoeira kernel: [1962364.950539] rr232x:ATA regs: error 40, sector count f4f4, LBA low 4480, LBA mid 8e, LBA high 70, device 40, status 41
Feb 26 04:35:02 capoeira kernel: [1962364.950542]
Feb 26 04:35:02 capoeira kernel: [1962364.962581] rr232x:start channel [0,2]
Feb 26 04:35:02 capoeira kernel: [1962364.962615] sd 0:0:2:0: [sdj] Result: hostbyte=DID_ABORT driverbyte=DRIVER_INVALID,SUGGEST_ABORT
Feb 26 04:35:02 capoeira kernel: [1962364.962620] end_request: I/O error, dev sdj, sector 1148227200
Feb 26 04:35:03 capoeira kernel: [1962365.504998] rr232x:channel [0,2] started successfully

Das ein paarmal hintereinander, danach gibt er auf und das Log wird von badblocks zugespammed, das pro Sekunde zehntausende (!) Fehler beim Beschreiben des Device meldet. Zum Glück ist Linux schlau und sagt nur:

Feb 26 04:37:42 capoeira kernel: [1962524.884689] printk: 63681 messages suppressed.

Himmelarsch, meine Fresse! Die oben genannte Festplatte steckt derzeit gleich fünf mal in meinem Server. Zwei teilen sich das RAID1 mit System und wichtigen beruflichen sowie privaten Daten, die anderen drei balgen sich im RAID5-Verbund um andere Userdaten.

Nun hat mein RAID-Controller in letzter Zeit verstärkt fehlerhafte Sektoren gemeldet, und zwar an gleich drei der Platten. So war ichs leid und habe mit Samsung telefoniert. Ein sehr freundlicher Hotline-Agent hat mir in Windeseile ein paar RMAs und Anweisungen zum reibungsfreien Garantietausch gemailt.

Nun bin ich, gerade was meine Daten angeht, ein vorsichtiger Mensch, außerdem brauchte ich ja ein bißchen Kapazität, um meine Daten zwischenzuspeichern. Also bin ich gleich am nächsten Tag, nämlich dem vergangenen Freitag, in den Münchner K&M-Shop gerannt und habe nochmal zwei Exemplare der Baureihe HE103UJ erstanden.

Beide auch gleich am Freitag eingebaut, dem RAID5 als Hot Spare gemeldet und eine der fehlerhaften Platten entfernt. Nach kurzem aber lauten Gepiepe des Controllers (“harddisk an port sowieso failed, hot spare took over”) legte selbiger auch schon los und kaum 6 Stunden später war das Array wieder “rebuilt”.

Heute Nachmittag wollte ich dann das selbe Spielchen mit der zweiten Platte durchziehen: Platte raus, Hot Spare springt ein, rebuilding, supi. Ein paar Stunden später, gerade auf dem Weg ins Bett, noch schnell den Rechner ausschalten… Hoppla, watt is das? RAID-Status CRITICAL? Rebuilding abgebrochen? Gut, nochmal anstoßen. Klick, ratterdiklack, “rebuilding failed. an error occurred on disk bla tüt”. WTF..?! Die Platte hab ich doch erst VORGESTERN gekauft?!?!

Dieser verfickte Drecksplatte ist doch tatsächlich gerade mal 48h am Stück gelaufen, bevor sie sich mit irreparablen Fehlern gemeldet hat! Und das allerschlimmste: Das ist exakt in dem Zeitfenster passiert, in dem sich das RAID im Rebuilding befunden hat, sprich: Null Toleranz bei Fehlern! 3 Stunden vorher – kein Problem, hätte ich halt das Rebuilden sein lassen und nur ein bißchen gekotzt! 3h später – kein Problem, dann wären alle Daten schon vollständig auf die neue Platte synchronisiert gewesen und der RAID-Verbund hätte – seinem Zweck entsprechend – gehalten.

Wie groß ist die verdammte Wahrscheinlichkeit, daß eine NAGELNEUE Platte nach so kurzer Zeit das zeitliche segnet und dann auch noch zu dem denkbar ungünstigsten Zeitpunkt, an dem NULL Datenredundanz herrscht, für die so ein blödes RAID nunmal entwickelt und in meinem Server eingerichtet wurde?!?!

Ich kann in diesem Leben niemals so viel fressen, wie ich KOTZEN möchte!

Ich habe nun ein RAID5-Array, das aus folgenden Platten besteht:

• alte, funktionstüchtige Platte mit Daten
• neue, funktionstüchtige Platte ohne Daten (da die Synchronisierung nicht komplett war)
• neue Platte mit Fehlern und Daten

Ich sitze nun seit gut 6 Stunden vor der Kiste, habe eine der alten 1TB-Platten mit reparierten Sektorfehlern reaktiviert und schaufele Daten drauf. Da die Daten nun teilweise von einer defekten Platte gelesen werden, kann ich hier schön fast jedes Verzeichnis einzeln kopieren. Und wenn wir über einen defekten Sektor stolpern, ist in der Regel Reboot angesagt, da der Controller das RAID dann deaktiviert.

Und das alles mache ich bei dem penetranten Gepiepe meiner USV, deren Akku vor ein paar Tagen ebenfalls den Geist aufgegeben hat. Und ich trau mich auch nicht, mich sinnlos zu besaufen, weil ich Angst habe, Flüchtigkeitsfehler zu machen.

Sooo sieht das aus, wenn demScroob sein RAID-Controller morgens wie irre piept und der Herr dringend nen Lüfter tauschen muß:

1: kaputter Lüfter.
2: Gehäuse, in dem neuer Lüfter schon drin is.

Mmmh… vllt. sollte ich mal nen fsck-Cron einrichten… home ging ja noch… aber /srv hat über ne Stunde zum Checken gebraucht… :-/

(ja, den bösen Error da oben hab ich gesehen. Der is aber eigentlich gar net schlümm…)

So… wenigstens is der Server nu mal wieder entstaubt. Und nen neuen Kernel hab ich vorm Runterfahren auch noch schnell installiert.

Juhu – heute morgen hat mir meine Nachbarin ein Paket in die Hand gedrückt. Innendrin: meine neue Server-Platte.

Leider hatte sich eine von den beiden Platten verabschiedet, die NICHT in einem HotSchwapp-Rahmen stecken, sondern fest eingebaut sind. Daher wars nix mit Operation am offenen Herzen und so wurde mein tänzelnder Server diese Woche zum zweiten und hoffentlich vorerst letzten Mal heruntergefahren.

Karp0tte Platte raus, neue Platte rein, Kabel dran, Saft! Beim Booten im RAID-BIOS die Platte initialisiert und als neue Spare Disk deklariert und Linux gebootet. Als der Apache lief und ich im RAID Manager nach dem rechten sehen wollte, hatte ich schon die erste Mail im Postfach, daß sich mein RAID_1_0-Array die neue Platte unter den Nagel gerissen hat und der Rebuild bei 5% sei. Kurz danach war wieder alles beim Alten.

Jetzt darf ich mich nur noch mit Alternate rumschlagen, daß ich von denen ne neue Platte kriege.

Wie Pinky nun sagen würde: “HappyHappyJoyJoy”.

Aaaaaaargh!!!

Ich habe es vor ein paar Monaten doch tatsächlich geschafft, meinen Server aus seinem Regal auszubauen, zwischenzulagern, den Serverschrank aufzubauen UND den Server dort komplett mit Switch und USV einzubauen OHNE ihn herunterfahren zu müssen. Ja, das war anstrengend.

Und JETZT… ziehe ich ihn so halb wieder raus, gucke mir die vielen bunten Käbelchen so an… und denk mir, ach ja doll, da ist Port 7, die Platte funkt ja noch… dann ziehste mal die 8 raus, machst nen Hottschwapp und guckst mal, obs vllt. nur am Kabel lag.

Dachte ich mir, griff zur sieben und zog kräftig dran. Mit dem Gejaule des RAID-Controllers hatte ich ja gerechnet. Aber weshalb plötzlich das RAID auf einmal komplett weg war, hab ich erst geschnallt, als ich bei mir so dachte “Mmmh… sieben… sieben? WAR DAS NICHT DIE GUTE?!?”

Tja, das hatte dann im Endeffekt – na? was? – genau: einen Reboot zur Folge. Schöne Uptime. ;( Der Dateisystem-Check hat für das verdammte 2TB-Array mindestens ne Viertelstunde gebraucht, Vielleicht sollte ich sowas mal schedulen…

Immerhin habe ich nun zweifelsfrei den Exitus der einen Platte festgestellt und gleich ne neue bestellt. Hoffentlich übermorgen da.

Merken: Fürs nächste Mal Teleskopschienen für den Server besorgen!

Gerade von meinem RAID-Controller eine Mail erhalten, daß mein RAID1-Array out of sync ist, daß es NICHT wiederhergestellt werden konnte und daß IRGENDWAS mit der einen Platte los sein soll.

Ist n super Zeitpunkt dafür, da ich gerade beim Kunden sitze und nicht wegkann. Aber ich hab mal grade alles aus dem gesamten Array gebackupt (oder heißt es gebackupped? Denglisch ist teilweise noch komplizierter als eine der Sprachen für sich…).

Gut: Die Datenmenge beträgt nur ca. 70 GB, war also schnell gesichert (ha, Denglisch ausgetrickst!).

Schlecht: Es handelt sich dabei um sämtliche User- und ein Großteil der Systemdaten des Servers.

Praktisch: Die Userdaten weren sowieso wöchentlich gesichert.

Nachher gleich ma schauen, ob sich ggfs. nurn Kabel gelockert hat oder so. Falls nicht, liegt eine Ersatzplatte innerhalb von 48h bei mir aufm Schreibtisch. Dafür geht danach das Gerenne mit Alternate los. Die Platte ist nämlich nicht mal ein Jahr alt.

Nachtrag:
An alle, die irgendwelche persönlichen Daten auf meinem Server liegen haben: Es ist alles in Ordnung! Es sind und werden keine Daten verloren gehen! Im schlimmsten Fall (die eine Platte IST gecrashed UND die zweite Platte crashed, BEVOR die erste ersetzt werden kann) sind sie für ca. 1-2 Tage nicht zugänglich.