<\/em><\/p>\n
![\"\"](\"\/de\/media\/greifensee.jpg\")
<\/p>\n
Die Konzepte der Datensicherung in der Virtualisierung sind unsicher!<\/h2>\n
Der Autor staunt immer wieder, wie blau\u00e4ugig 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\u00fchrt. 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\u00fchren.<\/strong><\/p>\n Damit sp\u00e4ter die G\u00e4ste „problemlos“ wiederhergestellt werden k\u00f6nnen, 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\u00fcck in den Zeitpunkt der damaligen Sicherung versetzt.<\/strong> d.h. der Gast wird r\u00fcckwirkend auf jenen Zeitpunkt wieder in Betrieb genommen, an dem die Hot-Swap-Datensicherung durchgef\u00fchrt wurde.<\/p>\n 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 \u00fcberpr\u00fcft wird, ob sich die Daten \u00fcberhaupt in einem statischen Zustand befinden.<\/strong> Im schlechtesten Fall liegt eine Sicherung vor, bei der das Betriebssystem sich selber aufgeh\u00e4ngt hat. Oder aber die gesicherten Dateien der Datenbankserver korrupt sind; <\/strong>im besseren Falle lassen sich diese dann mit hohem Zeitaufwand wieder restaurieren.<\/p>\n Bei Datenbank basierten Applikationen (im Server-Umfeld d\u00fcrfte dies die Regel sein) werden zwar oft in den G\u00e4sten 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\u00fcr die Virtualisierung als auch des Gastes zueinander passen. Was mag dabei tragisch sein? Ganz einfach, die virtualisierten G\u00e4ste k\u00f6nnen nur solange gesichert werden, wie der Anbieter der Software f\u00fcr die Virtualisierung entsprechende Plugins f\u00fcr die im Einsatz stehenden Betriebssysteme zur Verf\u00fcung 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\u00fcr XYZ‘, korrekterweise m\u00fcsste es heissen ‚Limitiert auf XYZ‘.<\/strong><\/p>\n Dabei k\u00f6nnte das Leben viel einfacher sein. Der Gastgeber (Sofware f\u00fcr Virtualisierung) und der Gast (virualisiertes Betreibssystem) arbeiten f\u00fcr sich autonom, bei den Datensicherungen wird der Gast kurz heruntergefahren, die Datensicherung durchgef\u00fchrt, und anschliessend wir der Gast wieder hochgefahren.<\/strong> Liegen die G\u00e4ste auf den Festplatten redundant vor, so kann die Zeit, in der der Gast nicht zur Verf\u00fcgung steht, \u00e4ussert kurz gehalten werden. Gast herunterfahren, 2. Festplatte aush\u00e4ngen, Gast hochfahren, Sicherung durchf\u00fchren, 2. Festplatte wieder einh\u00e4ngen.<\/p>\n Wo das Herunterfahren des Gastes nicht passt (im Linux-Umfeld ist dies mitunter verp\u00f6nt, lange Uptimes sind der Stolz jedes Admins), so k\u00f6nnen bei ArchivistaVM entsprechende Skripte vor und nach der Datensicherung ausserhalb des Gastes gestartet werden, die zuverl\u00e4ssig daf\u00fcr 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\u00fcher, auch hier wird es zunehmend w\u00fcnschenswert, immer den gesamten Gast zu sichern, um am Tag-X bei einem R\u00fcckspielen nicht doch die falsche Version des Datenbankservers vorliegen zu haben.<\/p>\n Das von ArchivistaVM verwendete Konzept wird leider bei L\u00f6sungen zur Virtualisierung nicht verwendet, obwohl nur bei diesem Konzept die Instanzen zu 100% statisch und autonom vorliegen.<\/strong> Das Konzept ben\u00f6tigt keine zus\u00e4tzliche Software zur Datensicherung, es k\u00f6nnen r\u00fcckwirkend beliebig viele Instanzen gesichert werden, es besteht keine Abh\u00e4nigkeit zu den G\u00e4sten, kurz und gut, es liegen standardkonforme Festplatten-Dateien vor, die wenn es sein muss, jederzeit hochgefahren oder auch offline ge\u00f6ffnet (dazu vielleicht demn\u00e4chst mehr)<\/strong> werden k\u00f6nnen.<\/p>\n Hinweis: Damit wir uns richtig verstehen, ArchivistaVM kann im qcow2-Format HotSwap-Sicherungen selbstverst\u00e4ndlich problemlos durchf\u00fchren, nur enthalten diese Sicherungen die gleichen M\u00e4ngel wie dies bei anderen L\u00f6sungen der Fall ist, und daher werden diese nachfolgend auch nicht weiter vorgestellt!.<\/strong><\/em><\/p>\n Selbstverst\u00e4ndlich k\u00f6nnen nur G\u00e4ste (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\u00fcpunkt ‚Datensicherung‘<\/strong> sowie bei ‚Jobs‘<\/strong> durch Klicken auf den Pfeil nach unten mit ‚Neuen Job erstellen‘<\/strong> die Datensicherung eingerichtet werden.<\/p>\n Nun k\u00f6nnen die Optionen f\u00fcr die Datensicherung festgelegt werden. Beachten Sie die Felder ‚Zielverzeichnis‘<\/strong> und ‚Externes Ger\u00e4t‘.<\/strong> Sofern kein externes Ger\u00e4t (Festplatte) festgelegt ist (nachfolgend f\u00fcr erste Versuche ist dies der Fall), erfolgt die Datensicherung in dieses Verzeichnis auf der internen Festplatte.<\/p>\n Hinweis:<\/strong> Nat\u00fcrlich sollte sp\u00e4ter die Sicherung auf eine externe Festplatte erfolgen, im Rahmen dieser Anleitung ist es jedoch angebracht, zun\u00e4chst die einfachere Variante (es ist keine externe Platte notwendig) zu \u00fcben.<\/em><\/p>\n Speziell erw\u00e4hnt soll hier das Feld ‚Speichern alte Backups (1-x)‘<\/strong> werden. Damit wird die Anzahl der Sicherungen festgelegt, ehe die letzte (\u00e4lteste) Sicherung \u00fcberschrieben wird.<\/p>\n Hinweis:<\/strong> Um die Datensicherung auf eine externe Festplatte<\/strong> einzurichten, muss bei ‚Externes Ger\u00e4t‘ die Kennung der Platte (z.B. \/dev\/sdb1, \/dev\/sdc1) angegeben werden.<\/strong> In diesem Fall dient das Zielverzeichnis als Einh\u00e4ngepunkt f\u00fcr das externe Ger\u00e4t; die G\u00e4ste selber werden nicht in dieses Zielverzeichnis gesichert, sondern direkt auf das externe Ger\u00e4t. Die Kennung des externes Ger\u00e4tes kann im Reiter ‚Wiederherstellen‘ erfragt werden.<\n\/strong><\/p>\n Hinweis II:<\/strong> Im Unterschied zu fr\u00fcheren Versionen von ArchivistaVM, k\u00f6nnen mit der aktuellen Version durchaus auch NTFS-formatierte Platten verwendet werden.<\/strong> Zu beachten gilt es dabei allerdings, dass bei mit NTFS-formatierten Platten kein Restore-on-the-fly<\/strong> m\u00f6glich ist.<\/p>\n Die Datensicherung ist nun f\u00fcr die gew\u00fcnschte Uhrzeit (vorliegend 2:00 Uhr) eingerichtet. Nat\u00fcrlich sollte der Job umgehend getestet werden. Dazu bitte auf den Pfeil nach unten beim entsprechenden Job klicken und dort ‚Jetzt starten‘ <\/strong>w\u00e4hlen. Es erfolgt eine Kontrollabfrage, ob die Sicherung gestartet werden soll, diese bitte best\u00e4tigen.<\/p>\n Die Datensicherung wird nun ausgef\u00fchrt. Die Log-Dateien k\u00f6nnen unter dem Men\u00fcpunkt ‚Datensicherung‘ mitverfolgt werden.<\/p>\n Die Datensicherung ist mit der Meldung ‚Finished Backup…‘ erstellt.<\/p>\n Um eine erstellte Sicherung zur\u00fcckzuspielen, steht beim Untermen\u00fc ‚Datensicherung‘ neben ‚Jobs‘ der Reiter ‚Wiederherstellen‘<\/strong> zur Verf\u00fcgung. Hier finden sich die vorhandenen Sicherungen.<\/p>\n Um eine Sicherung wiederherzustellen, muss die ID sowie die korrekte Version sowie eine neue ID f\u00fcr das R\u00fcckspielen eingetragen werden.<\/strong> In unserem Beispiel wird die ID 101 mit der Version 1 auf die ID 201 zur\u00fcckgespielt.<\/p>\n Nun kann der Vorgang mit dem Button ‚wiederherstellen‘<\/strong> ausgel\u00f6st werden. Auch hier gibt es unter dem Reiter ‚Jobs‘ Statusmeldungen. Der Vorgang ist dann abgeschlossen, sobald die Meldung ‚Restore successful‘ erscheint.<\/strong><\/p>\n<\/p>\n Hinweis:<\/strong> Bitte beachten, dieser Vorgang kann bei gr\u00f6sseren G\u00e4sten (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\u00fcr das R\u00fcckspielen<\/strong> zu erwarten.<\/p>\n Hinweis II: Bitte beachten, eine zur\u00fcckgespielte Instanz darf unver\u00e4ndert niemals gleichzeitig mit einer laufenden Instanz gestartet sein, weil dabei zweimal die gleiche Mac-Adresse sowie IP-Adresse(n) verwendet w\u00fcrden.<\/strong> Die Mac-Adresse kann bei der Instanz im Reiter ‚Hardware‘ ge\u00e4ndert werden, indem die Netzwerkkarte gel\u00f6scht und wieder hinzugef\u00fcgt (mit einer neuen Mac-Adresse) wird. Danach den Gast starten und die IP-Adresse(n) \u00e4ndern. Erst danach k\u00f6nnen (sofern dies notwendig sein sollte) beide Instanzen gestartet werden.<\/p>\n Um Instanzen auf eine externe Festplatte zu sichern,<\/strong> muss die korrekte Kennung (z.B: \/dev\/sdb1, \/dev\/sdc1) bei der Job-Definition eingegeben werden.<\/strong> Am einfachsten l\u00e4sst sich diese Kennung erfragen, indem zun\u00e4chst die angeschlossene (nicht eingeh\u00e4ngte) Platte im Reiter ‚Wiederherstellen‘ erfragt wird.<\/strong> Ist die Platte angeschlossen, so findet sich die Kennung bei ‚Externes Ger\u00e4t‘<\/strong> (in unserem Beispiel ist es \/dev\/sdb1).<\/p>\n Nun kann unter ‚Jobs‘ eine neue Datensicherung erstellt<\/strong> werden, bei der bei ‚Externes Ger\u00e4t‘ die erfragte Kennung eingetragen wird.<\/p>\n Hinweis: Sofern bei ‚Externes Ger\u00e4t‘ ein Eintrag steht, erfolgt die Datensicherung immer auf eine externe Festplatte.<\/strong> Ist der Eintrag nicht stimmig, erfolgt gar keine Sicherung, dies wird entsprechend in der Log-Datei protokolliert.<\/p>\n Hinweis II: Bei ‚Modus‘ finden Sie die beiden Optionen ‚Stop‘ und ‚Cluster‘. Mit der Option ‚Cluster‘ k\u00f6nnen Sicherungen in Cluster-Verb\u00fcnden (minimal zwei ArchivistaVM-Server) erstellt werden.<\/strong> Eine Instanz, welche auf dem ersten Knoten geischert werden muss, landet dabei auf dem letzten Knoten, alle \u00fcbrigen 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.<\/p>\n\n\n\n\tDas Konzept von ArchivistaVM<\/h2>\n
G\u00e4ste sichern und Wiederherstellen mit ArchivistaVM<\/h2>\n
![\"\"](\"\/de\/media\/backup\/backup1.png\")
<\/p>\n![\"\"](\"\/de\/media\/backup\/backup2.png\")
<\/p>\n![\"\"](\"\/de\/media\/backup\/backup3.png\")
<\/p>\n![\"\"](\"\/de\/media\/backup\/backup4.png\")
<\/p>\n![\"\"](\"\/de\/media\/backup\/backup5.png\")
<\/p>\nWiederherstellen einer Datensicherung<\/h2>\n
![\"\"](\"\/de\/media\/backup\/backup6.png\")
<\/p>\n![\"\"](\"\/de\/media\/backup\/backup7.png\")
<\/p>\n![\"\"](\"\/de\/media\/backup\/backup8.png\")
<\/p>\nSichern auf externe Ger\u00e4te (Festplatten)<\/h2>\n
![\"\"](\"\/de\/media\/backup\/backup9.png\")
<\/p>\n![\"\"](\"\/de\/media\/backup\/backup10.png\")
<\/p>\n