Murphy

Eigentlich hatte ich ein absolut sicheres Pannenkonzept für meine Server entwickelt:

1) Eine SSD /dev/sda hält /boot und daneben nur noch die Swap-Partition.
2) Zwei Festplatten /dev/sdb /dev/sdc bilden ein RAID-1 welches OS und Daten enthält.
3) Eine Festplatte /dev/sdd dient zur Speicherung der Backups.

Wie es Murphy will, sind letztes Wochenende gleichzeitig /dev/sdc und /dev/sdd weggeflogen – das RAID-1 tuckerte nur noch auf einer Festplatte und der Server hatte kein schreibfähiges Backupmedium mehr weil es RO eingebunden und aus diesem Status nicht wegzubringen war.

Aber eigentlich kein Problem: man geht auf einen Reserveserver und zieht alle Daten vom noch halblaufenden RAID-1 ab. Wo aber mindestens 50MB/s Datendurchsatz erwartet wurden, konnte nur mit ca. 800KB/s gelesen werden – es müssen „nur“ 300GB Daten kopiert werden, also 85 Stunden Laufzeit statt 2 Stunden.

Also meinen Kollegen von Pars Computer geschnappt und ab ins Rechenzentrum.

Der Ausfall von 2 Platten gleichzeitig deutete auf einen Fehler im SATA-Controller hin, also wurden auf Verdacht mal alle Festplatten in den Reserveserver umgesteckt. Im Prinzip eine gute Idee, aber aus irgendeinem Grund passte der Kernel auf der SSD nicht zur Reservemaschine (wtf?!) sodass ich halt wieder die SSD eingeschoben habe mit der dieser Reserve-Server installiert wurde.

Leider erwartete dieser Kernel den Rest seines Betriebssystems auf einem bestimmten RAID-1 und bekam nun ein anderes RAID vorgesetzt – „initram-fs“ kann sehr böse sein.

Am Ende habe ich alles wieder an den Start gebracht und nach 4 Tagen zeigte sich, dass nicht der Controller sondern die Platten selber kaputt sind weil die bekannten Übeltäter auch in der neuen Maschine aufmuckten.

Der Plan war dann einfach: defekte Platte im RAID-1 abmelden, neue rein und dem RAID-1 bekanntgeben. Angeblich kann die Hardware Hotplug (also im laufenden Betrieb Platte raus und rein), naja – bei mir crashte der Server und ich musste neu booten.

Mein Fehler: ich habe mir vorher nicht die UUIDs der Platten und des RAID-Arrays aufgeschrieben denn nach dem Reboot landete ich wieder in einer „initram-fs“ Shell weil angeblich der Rest des Betriebssystems nicht gefunden wurde.

In der Hektik hat es mich nicht gewundert, warum das neue RAID-1 Device /dev/md0 plötzlich eine neue UUID bekommen hat – nach dem nächsten Reboot habe ich es gesehen: statt dass die alten Daten auf die neue Festplatte gespiegelt wurden war es genau umgekehrt.

Damit waren meine aktuellen Daten futsch, blieb nur noch der Inhalt der Backupplatte. Die liess sich (mit etwas Kühlung) im Reserveserver einlesen und kopieren, halt der Stand vom letzten Samstag.

Dazu nochmal 3 Stunden wegkopieren der Datensicherung eines Kunden in der Hoffnung dass da genügend Informationen drin sind die letzten 7 Tage nachzuholen.

Wie sich herausstellte habe ich umsonst gewartet – es wird jeder Scheiss gesichert aber nicht das Relevante.

Ist aber jetzt nicht mehr mein Problem.

Dieser Beitrag wurde unter Dies und das... veröffentlicht. Setze ein Lesezeichen auf den Permalink.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*