Lob des Backups

Während ich diesen Artikel schreibe, rauschen im anderen Fenster die Zeilen der rsync-Ausgaben über den Bildschirm. Um 07:12 Uhr bemerkte Icinga die ersten Probleme; um 7:17 Uhr eskalierte es sie auf mein Handy. Seitdem bin ich wach, und weil ich während des nun laufenden Restores ohne nichts weiter unternehmen kann und die nächsten Schritte bereits vorbereitet habe, mache ich das Beste draus: Ich blogge.

Um’s direkt vorwegzunehmen: In technischer Hinsicht bietet dieser Blogpost keinerlei Erkenntnisgewinn. Nur vielleicht eine Moral, die da lautet: Macht Backups. (Und benutzt Sonnencreme, klar.)

Vom Monitoring aus dem Schlaf geholt zu werden, ist erstmal kein großer Aufreger. Nicht selten geht es hier um Probleme vom Kaliber „der Apache braucht mal einen Restart“ oder auch „die Mailqueue ist ungewöhnlich voll“ (was auf einen Spamvorfall hindeutet). Echte Ausfälle sind selten. In diesem Fall war es ein sehr kundenspezifischer Check: Es wird durch ein PHP-Script geprüft, ob eine ganz bestimmte Spalte einer ganz bestimmten Tabelle einer MySQL-Datenbank eine bestimmte Länge hat. Die Gründe für diesen Check führen hier zu weit; es gab vor längerer Zeit einen Vorfall, der dazu Anlass gab, und wir sind eigentlich immer bestrebt, für Vorfälle, die nicht durch unser Monitoring diagnostiziert wurden, anschließend noch bessere Checks zu schreiben. Dieser hier ist ein schönes Beispiel: Der Apache lief. Der MySQL-Server lief. Apache konnte auch mit MySQL kommunizieren. Aber MySQL konnte keine Daten schreiben. Das Gros der Checks des fraglichen Systeme meldete daher fröhlich „alles in Ordnung“ – obwohl überhaupt nichts in Ordnung war. Mir war nur noch nicht bewusst, wie sehr nicht.

Das ausgeführte DESCRIBE kunden führte jedenfalls zu einem Fehler, und zwar konkret zu Can't create/write to file '/tmp/#sql_2fc2_0.MYI' (Errcode: 30). Das muss jetzt erstmal noch keine Katastrophe sein, sondern kann auf simple Probleme wie eine überschrittene Quota oder eine vollgelaufene Partition hindeuten (was wir zwar auch monitoren, aber nur in einer niedrigeren Frequenz, weil sowas typischerweise nicht „von jetzt auf gleich“ passiert). Also habe ich mich dann erstmal per SSH eingeloggt, was auch geklappt hat.

Als df -h dann lediglich Command not found lieferte, und ps ax dann auch, war ich dann sehr schnell richtig wach, und es war klar: Das Problem ist größerer Natur als nur eine vollgelaufene /tmp-Partition. Auch dmesg ließ sich nicht mehr ausführen. Da es sich bei dem System um eine Xen-Instanz handelte, war von daher ein Login auf dem Wirtssystem dran. xm console zeige neben dem Login nur noch einen ext3-Fehler: Journal has aborted. Okay, das kommt mal vor. Selten. Und es ist in der Regel kein Problem, das sich nicht mit einem fsck.ext3 lösen ließe. Also: xm shutdown, xm create -c, … und das sah alles so gar nicht gut aus, denn pygrub mochte keine grub-Konfiguration innerhalb des Blockdevices des Gasts mehr finden.

Nun sieht dieses System so aus, dass eine lokal eingebaute Festplatte im physischen Server lediglich als Boot-Medium fungiert. Die Blockdevices hingegen kommen via iSCSI von unserem Storage-Cluster: Zwei dicke Maschinen mit je einem RAID6 über 16 Platten, die über DRBD repliziert werden, und auf denen dann LVM-Volumes via ietd exportiert werden. Schnell ein Login auf dem derzeit aktiven Filer: Gibt’s Probleme? Ein Blick in die Logfiles, in dmesg, … aber alles sah gut aus. Ich habe mich schnell auf einigen anderen Xen-Gästen eingeloggt, die ebenfalls vom Storage-Cluster aus exportiert werden, aber dort war alles in Ordnung, stabiler Betrieb, auch Schreibzugriffe problemlos möglich.

Im konkreten Fall ist auch der physische Server, auf dem die Xen-Instanz läuft, redundant ausgelegt: Via Heartbeat überwachen sich beide Hosts gegenseitig, und wer aktiv ist, bindet das iSCSI-Target ein und fährt die darauf enthaltene Xen-Instanz hoch. Das Setup läuft an sich prima und hat auch schon einige (geplante) Failover-Vorgänge überstanden. Ich hielt den Zeitpunkt für gegeben, einen Failover durchzuführen. Die Xen-Instanz war schnell gestoppt (tja, wenn das Linux-System erstmal nicht mehr auf sein Blockdevice schreiben kann, geht das verdammt fix …), dann ein iscsiadm --logout – und das hing. Und hing. Und hing. Was von daher merkwürdig war, weil der iSCSI-Server durchaus anpingbar war, also kein Problem mit dem Netzwerkinterface o.ä. vorliegen konnte.

In solchen Fällen ist es wichtig, eine Split-Brain-Situation zu vermeiden, sprich, es sollten nicht zwei Hosts das gleiche Blockdevice bearbeiten. Die einfachste Möglichkeit ist, den ohnehin praktisch toten Host komplett vom Strom zu trennen. Gesagt, getan – ist dank IPMI ja alles kein Problem. Dann die Übernahme des iSCSI-Targets auf den anderen Knoten, die von Heartbeat ohnehin automatisch veranlasst wurde, als der bisher aktive Host nicht mehr anpingbar war. Klappte. Mit einem kleinen Problem: Das Blockdevice beinhaltet eigentlich eine Partitionstabelle, die genau eine Partition umfasst, nämlich die Root-Partition. Wird das iSCSI-Target eingebunden, taucht es insofern als /dev/sdb auf (/dev/sda ist das eingebaute Boot-Plattensystem), und noch dazu ein /dev/sdb1 mit jener Root-Partition.

/dev/sdb war da. /dev/sdb1 fehlte. Ein fdisk -l /dev/sdb behauptete schlicht, es gebe keine Partitionstabelle. Das Blockdevice selbst hatte aber schon mal zumindest die korrekte Größe – der Zugriff via iSCSI an sich schien also zu klappen. Sicherheitshalber habe ich mir dann die Partition direkt auf dem Storage-Cluster angeschaut, um sicherzugehen, dass es wirklich kein iSCSI-Problem ist. Zum Vergleich, so sollte es aussehen (bei einem identisch eingerichteten Xen-Image):

[root@filer01 ~]# fdisk -lu /dev/mapper/vgdrbd1-vserver_working 

Disk /dev/mapper/vgdrbd1-vserver_working: 188.7 GB, 188743680000 bytes
255 heads, 63 sectors/track, 22946 cylinders, total 368640000 sectors
Units = sectors of 1 * 512 = 512 bytes

                              Device Boot      Start         End      Blocks   Id  System
/dev/mapper/vgdrbd1-vserver_working1   *           1   368627489   184313744+  83  Linux

Und so sah es faktisch aus:

[root@filer01 ~]# fdisk -lu /dev/mapper/vgdrbd2-vserver_broken 

Disk /dev/mapper/vgdrbd2-vserver_broken: 188.7 GB, 188743680000 bytes
255 heads, 63 sectors/track, 22946 cylinders, total 368640000 sectors
Units = sectors of 1 * 512 = 512 bytes

Disk /dev/mapper/vgdrbd2-vserver_broken doesn't contain a valid partition table

Okay, iSCSI selbst war als akute Fehlerquelle insofern aus dem Spiel. Es schien an der Zeit, TestDisk ins Spiel zu bringen. Dieses Tool ist Gold wert, wenn es darum geht, defekte Partitionstabellen zu fixen, unter anderem, in dem es die Platte sektorenweise nach Blöcken absucht, die z.B. wie ein ext3-Superblock aussehen – oder nach einem Backup davon, denn ext3 legt immer gleich mehrere Kopien des Superblocks verteilt über das Blockdevice an.

TestDisk fand nichts. Also wirklich überhaupt gar nichts. Insofern hatte ich wenig Hoffnung, dass der darauffolgende Schritt noch etwas bringen würde, nämlich die Partitionstabelle anhand eines identisch aufgesetzten VServers zu rekonstruieren. Aber bevor ich’s nicht versucht habe … erwartungsgemäß scheiterte aber der Versuch, die frisch angelegte Partition zu mounten (die ja eigentlich durchaus noch das Dateisystem hätte enthalten müssen – die Partitionstabelle zu bearbeiten, ändert ja nichts daran, dass auf dem Rest der Platte immer noch unverändert Daten liegen). Aus einem anderen Xen-Image identischer Konfiguration konnte ich noch die Positionen ableiten, die die Backup-Superblocks haben sollten, und habe sie alle durchprobiert – nichts.

An diesem Punkt war dann Schluss. Wir sind kein Datenrettungsunternehmen, und wir können auch nicht mal eben fix ein einzelnes LVM-Volume eines Clusters, auf dem noch ein paar Dutzend weiterer – voll funktionsfähiger – Volumes liegen, an ein solches schicken (wenn, dann müssten wir einen Klon des LVM-Volumes auf eine externe Platte anfertigen), und selbst wenn, würde das das Problem nicht lösen, dass das System im Moment eben nicht läuft. Insofern ist an dieser Stelle der Punkt gekommen, an dem ich mit hängenden Schultern sagen muss: Ich habe absolut keine Ahnung, was hier passiert ist. Der Storage-Cluster meldet weiterhin keinerlei Probleme. Sein RAID6 ist 100% in Ordnung (sagt der Controller). Und vor allem gab es ja keinerlei schreibenden Zugriffe auf Partitionstabelle oder Dateisystem des Images des Xen-Gasts, die irgendwie hätten fehlschlagen und etwas korrumpieren können – und Daten verschwinden eigentlich nicht „einfach so“, nicht ohne dass ein physischer Defekt vorliegen würde, was bei einem RAID-System mit vollkommen intakten Platten nun wirklich ausgesprochen unwahrscheinlich ist. Aber, wie’s aussieht, möglich.

Nun also rasseln die Dateien aus dem letzten Backup via rsync wieder zurück auf ein frisch angelegtes und mit einem Dateisystem versehenen Blockdevice. Der größte Datenblock, nämlich /home, ist schon durch, insofern kann es sich nur noch um Minuten handeln. Deshalb noch kurz ein Punkt im Hinblick auf Backups – darauf legen wir großen Wert: Insbesondere dort machen wir nichts mit proprietärer Software oder irgendwelchem Kompressions- oder diff-Gebastel. Die Gelegenheiten, bei denen uns rdiff-backup (dessen Konzept eigentlich ziemlich cool ist) im Stich gelassen hat, sei es durch absurd lange Restore-Zeiten selbst für einzelne Dateien, oder schlicht durch komplette Abbrüche mitten im Prozess, überwiegt die Zahl der Gelegenheiten, in denen es uns gerettet hat, bei weitem. Deshalb sind wir in Sachen Backup extrem konservativ: Ein extra Server mit eigenen Platten, keine komplizierten LVM-DRBD-Sonstwas-Layer dazwischen, einfach nur eine schnöde Partition angelegt, mit rsync kommen die Daten drauf. Versionierung läuft über Hardlinks. Auf diese Weise liegen zwei Versionen der gleichen Datei zwar nicht so platzsparend wie „erste Version plus Diff“ oder „letzte Version plus Reverse-Diff“ auf der Platte, aber dafür in einem Zustand, bei dem sich jeder Versionsstand mit Bordmitteln wie cp oder eben rsync schnell auf jede beliebige andere Hardware bringen lässt. Der Charme besteht eben nicht in Features, sondern manchmal schlicht im Weglassen selbiger.

So, die letzten Dateien laufen durch. In der Xen-Konfiguration ist bereits die disk-Zeile auf das neue Blockdevice angepasst. rsync fertig, umount, xm create -c. Bootet.

Die Maschine läuft nun also wieder, zwar mit einem Stand von gestern Nacht, aber eine bessere Option gibt es nun mal nicht. Downtime: Von 07:12 Uhr bis 11:01 Uhr – fast vier Stunden, was die Verfügbarkeit im Jahresmittel auf ärgerliche 99,95% herunterkatapultiert (wobei nur etwa eine halbe Stunde auf tatsächliche administrative Arbeiten entfällt – der Rest hingegen auf den Restore der Daten; man sollte also bei einem Backup nicht unterschätzen, dass auch ein Restore eine signifikante Downtime bedeuten kann). Aber der (ziemlich branchenspezifische) Shop wird nachts kaum besucht, am Wochenende noch weniger, von daher hält sich der potentielle Schaden wohl hoffentlich in Grenzen. Dass ein solcher Vorfall nun ausgerechnet bei einem System auftritt, wo sowohl die physischen Maschinen „vorne“ redundant ausgelegt sind als auch der Storage-Cluster „hinten“, ärgert mich um so mehr, aber es ist ein gutes Beispiel dafür, dass Hochverfügbarkeit durch Failover-Cluster auch nur eine Teilmenge möglicher Störungen absichert – und derart tiefgreifende Schäden an Dateisystemen und Partitionstabelle gehören nicht dazu. Die Lehren, die ggf. aus diesem Vorfall zu ziehen sind, werden wir dann am Montag im Teammeeting besprechen.

Also Leute, macht Backups. Gute Backups. Und vor allem vollständige Backups: Seid nicht zu selektiv – kopiert lieber zuviel als zuwenig, auch wenn man im Moment leider immer noch nicht wieder „Plattenplatz kostet doch eh fast nichts“ sagen kann. Und schaut gelegentlich, dass eure Backups auch funktionieren. Ihr wisst nie, wann sie euch mal den Allerwertesten retten.

So, jetzt erstmal Kaffee.

Tags: , ,

8 Antworten zu “Lob des Backups”

  1. Daniel sagt:

    Interessanter, gut geschriebener Artikel.
    Hattest Du auf dem DRBD-Slave auch mal auf die Platten geschaut? Da nur genau ein LVM Volume betroffen war, müsste der Fehler wohl auch oberhalb dieser Schicht passiert sein und dementsprechend auch repliziert worden sein, aber nachgucken würd ich ja trotzdem mal.

  2. Jonas Pasche sagt:

    Das ist leider nicht so ohne weiteres möglich, da wir DRBD hier ganz konventionell in einer Active-/Passive-Konstellation einsetzen und wir hier leider nur zwei große DRBD-Devices haben, die dann jeweils mittels LVM eine Volume Group und darauf dann entsprechend viele Volumes für die einzelnen Xen-Instanzen haben. Insofern ist das DRBD-Device auf dem anderen Host – da Secondary – nicht ansprechbar, und ein Failover nur dieses einen Volumes nicht machbar. Es bliebe von daher aus meiner Sicht maximal, direkt auf das zugrundeliegende Blockdevice auf dem Secondary (lesend) zuzugreifen, sozusagen unter DRBD durch. Das ist mir allerdings im Moment ehrlich gesagt etwas arg viel manueller Aufwand – zumal ich daraus dann auch keinen Erkenntnisgewinn ableiten könnte, woran genau es denn nun lag, dass auf einer Seite der Replikation plötzlich „alles weg“ war. DRBD ist an sich loggingmäßig ja – erfreulich – geschwätzig, hat hier auf den konkreten Systemen aber keine Silbe im Log hinterlassen.

  3. Sebs sagt:

    Genau mit solchen Posts erschleichst du dir die „credibility“ die wohl einige meiner Freunde zu euch treibt und auch meine nächste Empfehlung uberspace lauten lassen wird. Mal nicht zu wissen was passiert ist gehört auch dazu.

  4. Tim sagt:

    „Die Lehren, die ggf. aus diesem Vorfall zu ziehen sind, werden wir dann am Montag im Teammeeting besprechen.“
    Na dann schieß mal los. :D Würde mich echt sehr interessieren. :)

  5. Jonas Pasche sagt:

    In diesem konkreten Fall werden wir dem Kunden vorschlagen, statt Nutzung unseres Storageclusters stattdessen auf eingebaute Festplatten in den beiden Knoten zu wechseln – natürlich auch jeweils mittels RAID gespiegelt, und hier dann mit einem lokalen DRBD drüber. Die Kosten für den entsprechenden Umbau und die Nachrüstung lokaler Festplatten übernähmen dabei natürlich wir.

    Es ist ansonsten halt schwierig, wirkliche „Lehren“ aus dem Vorfall ziehen zu können, denn auch nach intensivem Austausch und noch einiger Überprüfungen konnte die Ursache von uns nicht ermittelt werden. Einerseits ist es zwar kein Anlass zu hektischem Aktionismus, wenn auf einem Storage-Cluster, der seit mehreren Jahren ausfallfrei läuft und einige Dutzend Volumes via iSCSI exportiert, mal ein Problem auftritt, auf der anderen Seite senkt es natürlich das „Grundvertrauen“ in eine bestimmte Technologie, die wir bisher für uns in allen Tests und dann auch in produktivem Betrieb eigentlich als „rock-solid“ erlebt hatten. Da wir aber auch aus anderen Gründen dabei sind, den betreffenden Storage-Cluster „zurückzubauen“ (nicht aufgrund von strukturellen Problemen, sondern weil die anfänglich sehr gute Performance beim verstärkten Einsatz ziemlich verschlechtert hat, obwohl wir mehrere mehrere dedizierte NICs verbaut haben, um den IO-Traffic zu separieren), ist dieser Vorfall für uns eher noch ein weiteres Argument, diesen Umbau voranzutreiben – auch wenn wir das zugrundeliegende Setup mit plattenlosen Hosts, die via gPXE vom Cluster booten und dabei auch ihr Root-Device via iSCSI erhalten, nach wie vor für eine ziemliche coole Sache halten.

  6. Tim sagt:

    Hallo Jonas,
    danke für die flotte, ausführliche und sogar mir verständliche Antwort! :)

    Mir ist jetzt allerdings nicht klar geworden, was ihr nun mit dem Storage Cluster machen wollt – du sprichst einmal von „zurückbauen“ (= die Maschinen Stück für Stück mit eigenen Festplattensystemen ausstatten) und einmal von „umbauen“ (= ?).

    Ich halte das Prinzip ebenfalls für eine „ziemlich coole Sache“, das Blog hier ist übrigens auch super. Habe jeden Artikel gelesen.

    Grüße

  7. Jonas Pasche sagt:

    Im Grunde meine ich mit Umbau/Zurückbau die gleiche Sache: „Zurückbauen“ in dem Sinne, dass wir versuchen, die Instanzen, die nach wie vor auf dem Storagecluster laufen, Stück für Stück ebenfalls in Standalone-Cluster zu migrieren – mit dem Ziel, den Storagecluster irgendwann in nicht allzu ferner Zukunft ausstellen zu können. Das sind halt hardwaretechnisch „Monster“, viele Platten, laut (okay, das ist im Rechenzentrum relativ egal), tonnenschwer und auch von der Leistungsaufnahme her nicht ganz ohne. Soll heißen, das ist eigentlich nur dann interessant, wenn man sie wirklich als Ersatz vieler Standalone-Plattensysteme verwenden kann, was im Prinzip auch viel effizienter wäre. Nur haben sich eben unsere Erwartungen an die Performance des Storageclusters in der Realität nicht in dem Maße erfüllt, wie wir uns das gedacht hatten, auch nach Aufrüstung um mehrere NICs nicht. Insofern befindet sich der Cluster derzeit in einem Zustand, wo schon Einiges weggezogen ist und dadurch die verbliebenen Hosts wieder angenehm flott darauf laufen – aber die opulente Storage-Hardware damit in keinster Weise so ausgelastet ist, dass der Betrieb irgendwie „wirtschaftlich“ wäre. Nun ja, auch wir lernen dazu.

  8. Axel Eble sagt:

    Ja, uns beißen Ausfälle auch immer da, wo wir nichts dran drehen können. Mal fallen zwei von drei Phasen Strom aus, mal bleibt irgendetwas halb am Leben anstatt komplett auszufallen – 100% Absicherung ist halt nie. Schade nur, dass die ganzen Verrenkungen mit Redundanz die eigentlichen Probleme nicht abfangen :)


Impressum