100% Datensicherheit beim Backup mit ArchivistaVM
Egg, 6. März 2014: In diesem Blog werden die Möglichkeiten bei der Datensicherung (Backup) mit ArchivistaVM vorgestellt. Die nachfolgend beschriebenen Möglichkeiten stehen sowohl in der kostenfreien ArchivistaBox Mini wie den kostenpflichtigen Versionen zur Verfügung. Der Einstieg erfolgt konzeptionell, indem aufgezeigt wird, warum die gängigen Sicherungsmethoden, welche derzeit in der Virtualisierung zur Anwendung kommen, im Ernstfall mit erheblichen Risiken behaftet sind, und weshalb die Datensicherung mit ArchivistaVM dies weithaus besser löst. Anschliessend erfolgt eine Schritt-für-Schritt-Anleitung, um die Datensicherung (inkl. das Wiederherstellen von Gästen) mit ArchivistaVM durchzuführen.
Die Konzepte der Datensicherung in der Virtualisierung sind unsicher!
Der Autor staunt immer wieder, wie blauäugig gestandene IT-Manager das Thema Datensicherung — gerade in der Virtualisierung — angehen. Fast immer werden in der Virtualisierung einzig sogenannte Hot-Swap-Sicherungen (es sind auch andere Namen wie Snapshots im Umlauf) durchgeführt. Hot-Swap bedeutet, dass vor der Sicherung die Maschine in einen statischen Zustand versetzt wird, um danach die Sicherung (ohne das Herunterfahren des Gastes) durchzuführen.
Damit später die Gäste “problemlos” wiederhergestellt werden können, wird zu den Festplatendateien meist auch der Hauptspeicher (RAM) mitgesichert, und zwar so, dass der Gast kurz eingefroren wird. Danach wird ein Abbild des Hauptspeichers (RAM) erstellt, das zusammen mit dem Inhalt der Festplattendabei(en) gesichert wird. Bei einem Wiederherstellen wird der gesicherte Inhalt des Hauptsichers (RAM) samt den Festplattendateien zurück in den Zeitpunkt der damaligen Sicherung versetzt. d.h. der Gast wird rückwirkend auf jenen Zeitpunkt wieder in Betrieb genommen, an dem die Hot-Swap-Datensicherung durchgeführt wurde.
Damit kann zwar erreicht werden, dass exakt jener Zustand wieder existiert, der bei der Datensicherung vorhanden war. Allerdings sind solche Sicherungen keinesfalls als statisch anzusehen, weil beim Hot-Swap-Eingriff nicht weiter überprüft wird, ob sich die Daten überhaupt in einem statischen Zustand befinden. Im schlechtesten Fall liegt eine Sicherung vor, bei der das Betriebssystem sich selber aufgehängt hat. Oder aber die gesicherten Dateien der Datenbankserver korrupt sind; im besseren Falle lassen sich diese dann mit hohem Zeitaufwand wieder restaurieren.
Bei Datenbank basierten Applikationen (im Server-Umfeld dürfte dies die Regel sein) werden zwar oft in den Gästen Plugins installiert, damit vor dem Erstellen des Speicherabbilds z.B. die Datenbanken kurz angehalten werden; dies bedingt aber, dass Plugins vorhanden sind, und dass die entsprechenden Versionen sowohl der Software für die Virtualisierung als auch des Gastes zueinander passen. Was mag dabei tragisch sein? Ganz einfach, die virtualisierten Gäste können nur solange gesichert werden, wie der Anbieter der Software für die Virtualisierung entsprechende Plugins für die im Einsatz stehenden Betriebssysteme zur Verfüung stellt. Oder anders herum gesagt, besteht zum zu verwendenden Betriebsystem kein Plugin, lassen sich gar nicht erst akkurate Datensicherngen (mehr) herstellen. Verkauft wird dies letztlich mit ‘Zertifiziert für XYZ’, korrekterweise müsste es heissen ‘Limitiert auf XYZ’.
Das Konzept von ArchivistaVM
Dabei könnte das Leben viel einfacher sein. Der Gastgeber (Sofware für Virtualisierung) und der Gast (virualisiertes Betreibssystem) arbeiten für sich autonom, bei den Datensicherungen wird der Gast kurz heruntergefahren, die Datensicherung durchgeführt, und anschliessend wir der Gast wieder hochgefahren. Liegen die Gäste auf den Festplatten redundant vor, so kann die Zeit, in der der Gast nicht zur Verfügung steht, äussert kurz gehalten werden. Gast herunterfahren, 2. Festplatte aushängen, Gast hochfahren, Sicherung durchführen, 2. Festplatte wieder einhängen.
Wo das Herunterfahren des Gastes nicht passt (im Linux-Umfeld ist dies mitunter verpönt, lange Uptimes sind der Stolz jedes Admins), so können bei ArchivistaVM entsprechende Skripte vor und nach der Datensicherung ausserhalb des Gastes gestartet werden, die zuverlässig dafür sorgen, dass die Daten im Gast in einem statischen Zustand vorliegen. Aber seien wir ehrlich, auch Linux-Betriebssysteme werden heute deutich zeitnaher aktualisiert als früher, auch hier wird es zunehmend wünschenswert, immer den gesamten Gast zu sichern, um am Tag-X bei einem Rückspielen nicht doch die falsche Version des Datenbankservers vorliegen zu haben.
Das von ArchivistaVM verwendete Konzept wird leider bei Lösungen zur Virtualisierung nicht verwendet, obwohl nur bei diesem Konzept die Instanzen zu 100% statisch und autonom vorliegen. Das Konzept benötigt keine zusätzliche Software zur Datensicherung, es können rückwirkend beliebig viele Instanzen gesichert werden, es besteht keine Abhänigkeit zu den Gästen, kurz und gut, es liegen standardkonforme Festplatten-Dateien vor, die wenn es sein muss, jederzeit hochgefahren oder auch offline geöffnet (dazu vielleicht demnächst mehr) werden können.
Hinweis: Damit wir uns richtig verstehen, ArchivistaVM kann im qcow2-Format HotSwap-Sicherungen selbstverständlich problemlos durchführen, nur enthalten diese Sicherungen die gleichen Mängel wie dies bei anderen Lösungen der Fall ist, und daher werden diese nachfolgend auch nicht weiter vorgestellt!.
Gäste sichern und Wiederherstellen mit ArchivistaVM
Selbstverständlich können nur Gäste (Instanzen) gesichert werden, wenn diese angelegt wurden, denn wo nichts ist, kann bekanntlich auch nichts gesichert wurden. Ist dies der Fall, kann in ArchivistaVM links der Menüpunkt ‘Datensicherung’ sowie bei ‘Jobs’ durch Klicken auf den Pfeil nach unten mit ‘Neuen Job erstellen’ die Datensicherung eingerichtet werden.
Nun können die Optionen für die Datensicherung festgelegt werden. Beachten Sie die Felder ‘Zielverzeichnis’ und ‘Externes Gerät’. Sofern kein externes Gerät (Festplatte) festgelegt ist (nachfolgend für erste Versuche ist dies der Fall), erfolgt die Datensicherung in dieses Verzeichnis auf der internen Festplatte.
Hinweis: Natürlich sollte später die Sicherung auf eine externe Festplatte erfolgen, im Rahmen dieser Anleitung ist es jedoch angebracht, zunächst die einfachere Variante (es ist keine externe Platte notwendig) zu üben.
Speziell erwähnt soll hier das Feld ‘Speichern alte Backups (1-x)’ werden. Damit wird die Anzahl der Sicherungen festgelegt, ehe die letzte (älteste) Sicherung überschrieben wird.
Hinweis: Um die Datensicherung auf eine externe Festplatte einzurichten, muss bei ‘Externes Gerät’ die Kennung der Platte (z.B. /dev/sdb1, /dev/sdc1) angegeben werden. In diesem Fall dient das Zielverzeichnis als Einhängepunkt für das externe Gerät; die Gäste selber werden nicht in dieses Zielverzeichnis gesichert, sondern direkt auf das externe Gerät. Die Kennung des externes Gerätes kann im Reiter ‘Wiederherstellen’ erfragt werden.< /strong>
Hinweis II: Im Unterschied zu früheren Versionen von ArchivistaVM, können mit der aktuellen Version durchaus auch NTFS-formatierte Platten verwendet werden. Zu beachten gilt es dabei allerdings, dass bei mit NTFS-formatierten Platten kein Restore-on-the-fly möglich ist.
Die Datensicherung ist nun für die gewünschte Uhrzeit (vorliegend 2:00 Uhr) eingerichtet. Natürlich sollte der Job umgehend getestet werden. Dazu bitte auf den Pfeil nach unten beim entsprechenden Job klicken und dort ‘Jetzt starten’ wählen. Es erfolgt eine Kontrollabfrage, ob die Sicherung gestartet werden soll, diese bitte bestätigen.
Die Datensicherung wird nun ausgeführt. Die Log-Dateien können unter dem Menüpunkt ‘Datensicherung’ mitverfolgt werden.
Die Datensicherung ist mit der Meldung ‘Finished Backup…’ erstellt.
Wiederherstellen einer Datensicherung
Um eine erstellte Sicherung zurückzuspielen, steht beim Untermenü ‘Datensicherung’ neben ‘Jobs’ der Reiter ‘Wiederherstellen’ zur Verfügung. Hier finden sich die vorhandenen Sicherungen.
Um eine Sicherung wiederherzustellen, muss die ID sowie die korrekte Version sowie eine neue ID für das Rückspielen eingetragen werden. In unserem Beispiel wird die ID 101 mit der Version 1 auf die ID 201 zurückgespielt.
Nun kann der Vorgang mit dem Button ‘wiederherstellen’ ausgelöst werden. Auch hier gibt es unter dem Reiter ‘Jobs’ Statusmeldungen. Der Vorgang ist dann abgeschlossen, sobald die Meldung ‘Restore successful’ erscheint.
Hinweis: Bitte beachten, dieser Vorgang kann bei grösseren Gästen (Instanzen) bis zu einige Stunden Zeit in Anspruch nehmen. Je nach verwendeter Schnittstelle (USB2/USB3) und Festplatte sind im Schnitt irgendwo um die 50 bis 200 MByte pro Sekunde für das Rückspielen zu erwarten.
Hinweis II: Bitte beachten, eine zurückgespielte Instanz darf unverändert niemals gleichzeitig mit einer laufenden Instanz gestartet sein, weil dabei zweimal die gleiche Mac-Adresse sowie IP-Adresse(n) verwendet würden. Die Mac-Adresse kann bei der Instanz im Reiter ‘Hardware’ geändert werden, indem die Netzwerkkarte gelöscht und wieder hinzugefügt (mit einer neuen Mac-Adresse) wird. Danach den Gast starten und die IP-Adresse(n) ändern. Erst danach können (sofern dies notwendig sein sollte) beide Instanzen gestartet werden.
Sichern auf externe Geräte (Festplatten)
Um Instanzen auf eine externe Festplatte zu sichern, muss die korrekte Kennung (z.B: /dev/sdb1, /dev/sdc1) bei der Job-Definition eingegeben werden. Am einfachsten lässt sich diese Kennung erfragen, indem zunächst die angeschlossene (nicht eingehängte) Platte im Reiter ‘Wiederherstellen’ erfragt wird. Ist die Platte angeschlossen, so findet sich die Kennung bei ‘Externes Gerät’ (in unserem Beispiel ist es /dev/sdb1).
Nun kann unter ‘Jobs’ eine neue Datensicherung erstellt werden, bei der bei ‘Externes Gerät’ die erfragte Kennung eingetragen wird.
Hinweis: Sofern bei ‘Externes Gerät’ ein Eintrag steht, erfolgt die Datensicherung immer auf eine externe Festplatte. Ist der Eintrag nicht stimmig, erfolgt gar keine Sicherung, dies wird entsprechend in der Log-Datei protokolliert.
Hinweis II: Bei ‘Modus’ finden Sie die beiden Optionen ‘Stop’ und ‘Cluster’. Mit der Option ‘Cluster’ können Sicherungen in Cluster-Verbünden (minimal zwei ArchivistaVM-Server) erstellt werden. Eine Instanz, welche auf dem ersten Knoten geischert werden muss, landet dabei auf dem letzten Knoten, alle übrigen Instanzen auf dem vorangehenden Knoten. Dies ist zu beachten, damit die Festplatte am richtigen Knoten angeschlossen wird. Beispiel: Eine Instanz, die auf dem erten Knoten eines 2er-Clusters gesichert werden soll, landet auf der Festplatte des zweiten Knotens; das Anschliessen der Platte am ersten Knoten wird nicht funktionieren.
