ForumBackup und Restore
From RootForum Community » Wiki
Contents |
Einleitung
Die Festplatte hat einen Head Crash, der Server wurde gehackt, im Tran in der falschen Konsole ein rm -rf * .??* abgesetzt – gut, wenn man in einer solchen Situation ein Backup zur Hand hat. Besser, wenn das Backup sogar aktuell ist. Noch besser, wenn man jetzt auch noch wüßte, wie genau man das System aus den vorhandenen Backups wieder herstellt, ohne noch mehr Schaden anzurichten oder unnötig Zeit zu verplempern…
Backups sind für den Notfall gedacht. Jeder, der Murphy kennt, weiß auch, dass solche Notfälle grundsätzlich in den ungünstigsten Situationen auftreten. Kurz vor Feierabend, am Wochenende, mitten in der Nacht – kurzum immer dann, wenn man sie so gar nicht brauchen kann. Das verbreitet Streß und Hektik. Um in einer solchen Situation keinen Fehler zu machen oder die Hektik durch unklare Abläufe noch zu vergrößern, lohnt es sich in jedem Fall, sich auf eine solche Situation vorzubereiten. Nur ein Backup zu haben genügt nicht; das Backup muss für den vorliegenden Fehlerfall die richtigen Daten bereithalten, und die Handgriffe, die für die Wiederherstellung vonnöten sind, dürfen nicht erst durch Versuch und Irrtum erarbeitet werden müssen.
Systemaufbau und Recovery-Szenarien
Bausteine eines Systems
Die nebenstehende Abbildung illustriert, aus welchen aufeinander aufbauenden Bausteinen ein Serversystem besteht. In älteren Darstellungen wäre dieses Bild zumindest beim Speicherlayout noch strenger hierarchisch ausgefallen, aber in Zeiten moderner Speicherverwaltungstechniken wie ZFS, GEOM oder Device-mapper verschwimmt die Grenze zwischen Partitionierung und Dateisystem zunehmends.
Müssen alle diese Bausteine bei einem Restore von ganz unten wieder aufgebaut werden, so spricht man von einem „Bare Metal Recovery“ – man fängt sozusagen auf dem nackten (Server-) Blech an. Auch die Dringlichkeit einer Recovery-Aktion lässt sich anhand dieses Schemas verdeutlichen: Ist nur ein Baustein einer einzelnen Anwendung (also auf der obersten Ebene) betroffen, so sind die übrigen, auf dem selben System arbeitenden Anwendungen nicht beeinträchtigt. Der Schaden ist also begrenzt und die Dringlichkeit für die Wiederherstellung bemisst sich am SLA für die betroffene Anwendung. Ist jedoch ein Baustein weiter unten betroffen, sind alle Anwendungen oder Dienste auf dem System beeinträchtigt und es steigt die Wahrscheinlichkeit, dass eine Anwendung mit besonders hohen Verfügbarkeitsanforderungen ausgefallen ist.
Das ist natürlich eine starke Vereinfachung. Allein auf Anwendungsebene gibt es in der Regel Abhängigkeiten zwischen einzelnen Anwendungen; so wird etwa der MTA streiken, wenn Spam- oder Virenscanner den Dienst verweigern, und viele Webanwendungen sähen ohne Datenbankserver als Backend recht alt aus. Darüber hinaus ließe sich das Schema noch beliebig verkomplizieren, wenn man durch Virtualisierung hinzukommende Schichten mit einbezieht. Für den Gegenstand dieses Artikels genügt allerdings das vereinfachte Schema, da weitere Ebenen die bereits gezeigten Bausteine nur wiederholen würden.
Wahl der Waffen
Im Falle eines Falles gilt es also, die oben aufgezeigte Struktur Stück für Stück wieder zusammenzusetzen; im schlimmsten anzunehmenden Fall von ganz unten bis ganz oben. Nun ist es an der Zeit, einmal darüber nachzudenken, in welcher Form die Puzzlestücke am besten vorliegen sollten, damit ein reibungsloser Restore-Prozess gewährleistet ist.
Planen für den Katastrophenfall
Für einen Notfallplan muss man immer vom schlimmsten anzunehmenden Fall ausgehen; weniger desaströsen Fällen kann man dann zumeist mit einem Teil des Notfallplans recht gut begegnen. Auf einen Server übertragen bedeutet dies: Was tun bei einem Totalausfall?
Diagnose
Bei einem remote stehenden System (z. B. gemieteter Server oder Server im Housing-Betrieb) gestaltet sich schon die Diagnose oft recht schwierig. Machen Sie sich daher auch in jedem Fall Gedanken dazu, wie Sie möglichst schnell ein klares Schadensbild erhalten! Denn erst wenn Sie wissen, mit welchen Schäden Sie es zu tun haben, können Sie mit deren Behebung beginnen. Klingt trivial? Dann versuchen Sie einmal, bei einem nicht mehr erreichbaren System herauszubekommen, ob das System aufgrund eines Software-Problems abgestürzt ist, aufgrund eines Netzwerkkartendefekts nicht mehr antwortet oder gar die Festplatten in die ewigen Jagdgründe eingegangen sind.
Die meisten Provider bieten für Mietserver ein Rettungssystem an. Dieses ist zumindest hilfreich, um Software-Probleme (Logdatei-Analyse) sowie Schäden an Dateisystemen (fsck) oder Festplatten (smartmontools) zu diagnostizieren. Damit die Diagnose reibungslos klappt, sollte auf einem Notfallplan vermerkt sein, wie das Rettungssystem aktiviert wird und wie ggf. fehlende Diagnosewerkzeuge nachgerüstet werden können (ggf. selbst gebrauchsfertige Binaries bereithalten). Außerdem ist es hilfreich, die einzelnen Diagnoseschritte in Form einer Checkliste griffbereit zu haben, die das zu verwendende Werkzeug nebst zu verwendender Kommandozeilenoptionen aufführt und ggf. bei der Interpretation der Ergebnisse behilflich ist.
In einigen Fällen (insbesondere bei Hardware-Schäden) wird man jedoch kaum ohne die Unterstützung eines Technikers vor Ort auskommen. Es ist daher wärmstens zu empfehlen, auf einem Notfallplan auch entsprechende Rufnummern für Service-Hotlines nebst deren Service-Zeiten zu notieren. Die Zeiten helfen ungemein, um unnütze Überstunden zu vermeiden und ein grobes Gefühl dafür zu bekommen, in welchem Zeitrahmen ein Recovery des ausgefallenen Systems überhaupt möglich ist.