Es gibt ein Sprichwort aus "The Tao of Backup", das in den Tagen von NT4 geschrieben wurde und lautet:
An seine Backups zu glauben ist eine Sache. Sie nutzen zu müssen, eine andere.
Dies wird häufig verkürzt als "Testen Sie Ihre Wiederherstellungen" oder:
Wenn Sie Ihre Wiederherstellungen nicht getestet haben, haben Sie keine Backups.
Das ist alles schön und gut, aber in heterogenen Computerumgebungen kann es etwas schwierig werden. Sie können SureBackup verwenden, um Ihre Windows-VMs zu testen, aber was ist mit Ihrem Windows XP-System, das Ihre CNC steuert? Und was ist mit dem Solaris 9-Rechner, auf dem Ihr Oszilloskop läuft?
Die Dinge können sogar noch komplizierter werden... was, wenn Ihr Solaris 9-System Kerberos-Authentifizierung verwendet und erfordert, dass der Controller zuerst wiederhergestellt wird?
Viele moderne Tools versprechen einen Knopfdruck zum Testen der Backups... das ist toll, aber sie funktionieren nur, wenn alle Ihre Systeme die Kriterien erfüllen. Ein physisches Altsystem in der Mischung... und plötzlich sind Sie ungeschützt - und das ist das System, das am ehesten ausfallen kann!
Die Strategie
Als Erstes muss herausgefunden werden, wie die Systeme und Daten manuell wiederhergestellt werden können, und dieser Prozess muss dokumentiert werden.
Ein Beispiel für einen Solaris 9-Wiederherstellungsplan könnte lauten:
- Flar-Image von der Festplatte mit dem Installationsprogramm wiederherstellen
- Wiederherstellung von Daten mit tar vom Band
- Boot
- Testbefehle ausführen
Ein Beispiel für eine VM-Wiederherstellung könnte dagegen einfach sein:
- Wählen Sie den Plan zur Wiederherstellung der VM von ${Sicherungsprodukt hier einfügen}
Wenn der Solaris 9-Rechner darauf angewiesen ist (z. B. weil er Kerberos-Authentifizierung bietet), müssen Sie die beiden Systeme leider kombinieren. Sie müssen sich im selben VLAN befinden, in einer bestimmten Reihenfolge booten und in dieser Reihenfolge getestet werden.
Ein Beispielplan
Ein Beispielplan für einen Solaris 9-Rechner, der mit einem A/D auf Kerberos verbunden ist, könnte so aussehen:
| Solaris-Maschine | A/D-Steuerung |
|---|---|
| Flar-Image von der Festplatte wiederherstellen | Wiederherstellungs-VM-Image |
| Wiederherstellung von Daten mit tar vom Band | Boot-VM-Abbild |
| WARTEN → | Test A/D-Controller |
| Solaris-Maschine booten | |
| Test-Solaris-Maschine |
Selbst in einem einfachen Fall besteht eine Abhängigkeit von einem Test vor dem Booten. In einem komplizierteren Szenario können wir mehrere Abhängigkeiten haben. Nehmen wir zum Beispiel an, wir haben eine Webschnittstelle zu einer Solaris-Legacy-Anwendung, die auf einem LAMP-Stack läuft:
| LAMP-Stapel | Solaris-Maschine | A/D-Steuerung |
|---|---|---|
| VM-Abbild wiederherstellen | Flar-Image von der Festplatte wiederherstellen | VM-Abbild wiederherstellen |
| Wiederherstellung von Daten mit tar vom Band | Boot-VM-Abbild | |
| WARTEN → | Test A/D-Controller | |
| Solaris-Maschine booten | ||
| WARTEN → | Solaris-Anwendung testen | |
| Linux-Maschine booten | ||
| Test Web UI |
Das wird funktionieren, aber es gibt noch weitere Probleme:
- Was ist, wenn das Booten des Solaris-Rechners sehr lange dauert? Wäre es nicht schön, wenn man ihn früher starten könnte?
- Wenn die Wiederherstellung von Linux auf Betriebssystemebene fehlschlägt, könnten wir das ohne die anderen Maschinen herausfinden. Dasselbe gilt für die Solaris-Maschine - und diese Wiederherstellung könnte lange dauern, wenn die Daten von einem Band zurückkommen...
| LAMP-Stapel | Solaris-Maschine | A/D-Steuerung |
|---|---|---|
| VM-Abbild wiederherstellen | Flar-Image von der Festplatte wiederherstellen | VM-Abbild wiederherstellen |
| Webdienst deaktivieren | Anwendung deaktivieren | Boot-VM-Abbild |
| Boot | Boot | |
| Testbetriebssystem ist betriebsbereit | Testbetriebssystem ist betriebsbereit | |
| Wiederherstellung von Daten mit tar vom Band | ||
| WARTEN → | Test A/D-Controller | |
| WARTEN → | Solaris-Anwendung testen | |
| Aktivieren Sie den Webdienst | ||
| Test Web UI |
Jetzt haben wir also einen Plan, der im Falle eines Betriebssystemfehlers so früh wie möglich scheitern wird. Dies kann wahrscheinlich noch weiter verbessert werden; es könnte möglich sein, eine Teilmenge von Daten wiederherzustellen, um einen schnellen Anwendungstest vor dem langsamen durchzuführen, es könnte möglich sein, die Web-UI (teilweise) isoliert zu testen usw...
Anforderungen an die Automatisierung
Ein solcher Plan erfordert:
- Eine Orchestrierungsplattform mit freier Kontrolle über die Bereitstellung
- Skripting nach der Wiederherstellung vor dem Neustart zur Steuerung des bootenden Betriebssystems
- APIs zum Booten wiederhergestellter Maschinen für eine Vielzahl von Plattformen
- Eine Testplattform mit einer API
Werkzeuge für den Job
Eine Orchestrierungsplattform
Wir verwenden Jenkins zur Verwaltung dieses speziellen Vorgangs, da Jenkins in unserem Fall auch die Erstellung der Wiederherstellungssoftware verwaltet. Jenkins kann leicht mit Skripten versehen werden und verfügt über Plugins für die wichtigsten VM-Anbieter, so dass es für viele Organisationen eine gute Grundlage darstellt.
Wiederherstellung und Skripting nach der Wiederherstellung
Natürlich empfehlen wir Cristie BMR, das Solaris, Linux und Windows (und AIX) unterstützt und ein Post-Recovery-Skripting bietet. Es ist aber auch möglich, dies stückweise mit verschiedenen Tools zu tun: JumpStart kann mit Solaris und FLAR sehr effektiv eingesetzt werden, auch wenn dies mit einigem Aufwand verbunden ist. Die Skripterstellung nach der Wiederherstellung einer VM kann schwierig sein, aber das Booten in eine Linux-Live-Umgebung nach der Wiederherstellung der VM würde gut funktionieren.
APIs zur Steuerung des Bootvorgangs
Alle Hypervisoren haben APIs zum Booten von VMs... aber was ist mit physischen Kits? Eine Lösung, die wir verwenden, ist die Verbindung über einen seriellen Port und die Verwendung von pyserial zur Orchestrierung der Maschine.
Eine Testplattform
Hierfür verwenden wir wieder Jenkins, führen aber Skripte mit Bats aus. Dies ist eine gute Möglichkeit, sehr schnell einige einfache Prüfungen zu schreiben, die in Jenkins angezeigt werden können. Eine umfassendere Lösung wäre jedoch die Verwendung von serverspec oder ähnlichem.
Beispiel
Das Jenkins-Plugin "blue-ocean" bietet einen sehr klaren Überblick über den Fortschritt eines Tests: In diesem Stadium haben wir begonnen, Cristie CBMR zu verwenden, um ein Solaris 9-System auf physischer Hardware wiederherzustellen. Nach der Fertigstellung wird ein kurzes Skript die erforderliche Anwendung beim Booten deaktivieren und die beim Booten zu verwendenden Netzwerkparameter einrichten.
Das Python-Skript, das dies durchführt, wird:
- Booten Sie den Rechner per Netzwerk-Boot von einem PXE-Server, der das CBMR-Image enthält
- Starten Sie die Wiederherstellung aus dem OS-Backup
Nach Fertigstellung kann auf den Rechner über das Netzwerk statt über die serielle Konsole zugegriffen werden, und es kann das Standard-Jenkins-Skripting verwendet werden.
Fertigstellung
Die Pipeline führt jede Stufe nur der Reihe nach aus, so dass Stufen zur Trennung gleichzeitiger Aktionen verwendet werden.
Aus dem obigen Plan geht hervor, dass der A/D getestet werden muss, bevor die Anwendung gestartet werden kann, dass die Anwendung gestartet werden muss, bevor der Webdienst gestartet wird, und dass der Webdienst erst getestet werden kann, nachdem er gestartet wurde. Es ist möglich, das "Lockable resource plugin" zu verwenden, um eine feinere Kontrolle zu erreichen, aber das ist schwieriger und birgt größere Risiken.
Am Ende des Wiederherstellungstests erhalten wir die folgende (stark gekürzte) Ausgabe und eine Protokolldatei:
Zusammenfassung
Es ist möglich, moderne CI-Tools zu verwenden, um die Wiederherstellung älterer Betriebssysteme zu testen, sofern die Tools dies unterstützen:
- Eine API zur Steuerung der Umgebung, die gebootet werden soll
- Eine API zur Kontrolle, wann die Umgebung gebootet wird
- Orchestrierungs-Hooks zur Bereitstellung von Umgebungen für die Wiederherstellung
Viele Sicherungssysteme bieten diese Möglichkeiten nicht. Insbesondere gibt es nur wenige Tools, mit denen Sie eine Wiederherstellungsumgebung bereitstellen können.
TBMR
TBMR wurde für die Wiederherstellung der Betriebssysteme verwendet. Es wurde für die Arbeit mit Windows, Linux, Solaris und AIX entwickelt:
