Backup-Strategien für Hyper-V-Systeme: Teil 4

Um welche Bereiche müssen sich die Backup-Beauftragen vermehrt kümmern? Bestehende Konzepte basieren meist auf einen entsprechenden Erfahrungsschatz. Allerdings sollten die Systembetreuer derartige Herangehensweisen durchaus von Zeit zu Zeit neu überdenken. Denn wenn eine bestimmte Lösung sich bisher als „allgemeingültig“ herausgestellt haben, müssen diese nicht in jedem Szenario angewandt werden. Wechselnde Gegebenheiten erfordern unter Umständen auch ein Umdenken beim Thema Backup.

Um die Hypervisor-Systeme und die einzelnen VMs zu sichern können die Systembetreuer auf unterschiedliche Strategien setzen. Etwa können die Systembetreuer Hyper-V-Systeme wie „ganz normale“ Server behandeln. Sprich es werden komplette Vollsicherungen mit den entsprechenden Backup-Anwendungen erstellt. Dabei sichern die Administratoren sowohl das Betriebssystem, die Anwendungen und die einzelnen Daten auf dem Server. Dazu sind bereits unterschiedliche bereiche in Teil 1, Teil 2 und Teil 3 dieser Beitragsreihe näher beleuchtet worden.

Etwa können die IT-Betreuer bei einem Ausfall die Server komplett wiederherstellen, inklusive OS, Treibern, Konfigurationen, Einstellungen Anwendungen und Nutzdaten. Dies lässt sich mit vielen Backup-Anwendungen noch weiter verbessern: Mit den entsprechenden Tools ist dabei sogar eine Rücksicherung auf abweichender Hardware möglich. Sprich falls das „Serverblech“ mit einem Mainboard-Schaden (oder einem ähnlichen Fehler) ausfallen sollte, besteht trotzdem die Möglichkeit einer kompletten Systemwiederherstellung auf einem komplett unterschiedlichen System. Solch eine Hardware-unabhängige Bare-Metal-Recovery ist besonders dann wichtig, wenn keine identischen Ersatzsysteme besorgt werden können.

Hardware-unabhängige Komplettwiederherstellung

Grundsätzlich wird diese hardwareunabhängige Systemwiederherstellung mit einem Trick erreicht: Denn zwischen Betriebssystem und der eigentlichen Hardware befindet sich bei Windows-Betriebssystemen eine zusätzliche „Schicht“ Dieser HAL (Hardware Abstraction Layer) ist beispielsweise der Grund, warum aktuelle Windows-Betriebssysteme (relativ) stabil sind. Denn ohne HAL haben das OS und auch die einzelnen Applikationen direkten Zugriff auf die Hardware. Falls die Anwendungen nun beispielsweise (wie beim „alten“ MS-DOS) direkten Zugriff auf einzelne Speicheradressen eingeräumt bekommen, führt ein Fehler bei der Anwendung unter Umständen zu einem kompletten Systemabsturz. Und eben dieses Verhalten soll bei aktuellen Betriebssystemen eben nicht möglich sein, denn die Anwendungen werden immer komplizierter. Schließlich können beim Umfang der Quellcodes Fehler auch bei sorgfältigster Programmierung nicht ausgeschlossen werden.

Durch diesen HAL kommt es nun aber zu Problemen, wenn man beispielsweise ein Systemabbild auf einem System mit abweichender Hardware (im Vergleich zur Abbild-Quelle) rücksichert. Denn plötzlich „kennt“ sich das OS nicht mehr aus, wenn es quasi in ein anderes System „gebeamt“ wird. Um dieses Problem zu umgehen, setzen diese Backup-Programme den HAL quasi wieder in den „Urzustand“ zurück, wie er etwa auch direkt nach einer Windows-Installation vorkommt. Bei einer Neuinstallation müssen die Systembetreuer dann die herstellerspezifischen Treiber aufspielen, dies ist beim hardwareunabhängigen Restore ebenfalls nötig. Allerdings können die Systembetreuer diese Treiberdateien (meist im INF- beziehungsweise OEM-Format) bei der Rücksicherung gesondert angeben. Damit kümmert sich das Backup-Programm um die korrekte Implementierung der Treiber direkt während des Wiederherstellungsvorgangs.

Anwendungen und VMs im Fokus

Alternativ können sich die Systembetreuer auch auf den eigentlichen Workload konzentrieren, und den Hypervisor selbst (zunächst) außen vor lassen. Denn im Prinzip sind die VMs ja in ihren Containern (beispielsweise im VHD- oder VHDX-Format) komplett enthalten. Wenn nun diese Dateien entsprechend gesichert sind, befinden sich die Systembetreuer unter Umständen bereits auf „der sicheren Seite“. Denn die Arbeitsdaten, installierte Anwendungen oder ähnliche Dienste befinden sich ja in den VMs. Somit kann es bereits reichen, wenn diese entsprechend in das Sicherungskonzept integriert sind. Nun könnten aufmerksame Administratoren anmerken, dass in solch einem Fall ja der Hypervisor neu installiert werden muss.

Dies ist auch richtig, aber im Anschluss daran müssten die Systembetreuer die Netzwerkverbindung (etwa den internen Switch) konfigurieren die VMs hinzufügen, starten und diese auf ihre Funktion testen. Danach ist der Produktivbetrieb wiederhergestellt. Nun stellt sich eher die Frage, welche Variante weniger Aufwand bedeutet, und in welcher Zeitspanne die Administratoren mit der jeweiligen Variante wieder die volle Einsatzfähigkeit der Systeme erreichen.

Um nach einer Neuinstallation des Hypervisor diesen möglichst schnell einsatzbereit zu bekommen, bieten sich unterschiedliche Methoden an. So können die Systembetreuer etwa die notwenigen Konfigurationsschritte dokumentieren, und sich die benötigten Einstellungen entsprechend notieren. Alternativ erzeugen die Administratoren passende Skript-Dateien (etwa mit der Windows Powershell), um die jeweiligen Konfigurationsschritte zu automatisieren. Beispielsweise lassen sich Einstellungen zur Hostnamenskonvention, den verwendeten IP-Adressen, Subnetzen oder DNS-Einstellungen in einem ersten Powershell-Skript zusammenfassen. Weitere Schritte (etwa Einstellungen der virtuellen Switches und Parameter für die VMs können die Verantwortlichen in einem zusätzlichen Skript abspeichern.

Auf diese Weise können die Systembetreuer den Hypervisor beispielsweise installieren, die benötigten Treiber aufspielen, das erste Skript ausführen, und den Server neu starten. Nun werden beispielsweise die VM-Container wieder auf das System übertragen, oder die entsprechenden Netzwerkspeicher (mit den VMs) am Server angebunden. Im nächsten Schritt könnten dann (etwa wenn der Domänenbeitritt bereits Teil des ersten Skripts war) die virtuellen Netzwerkadapter automatisch eingestellt werden. Danach starten die Systembetreuer die einzelnen VMs (auch dies ist wiederum mittels eines entsprechenden PS-Skripts möglich): Das System ist nun komplett wiederhergestellt.

Falls allerdings auf dem Hypervisor weitere Dienste installiert sein sollten, ist es unter Umständen nicht zielführend, nur die VM-Container zu sichern. Denn in diesen Fällen macht die Neuinstallation des Hyper-V-Servers (und der zusätzlichen Workloads) meist deutlich mehr Aufwand. Allerdings sollten die Systembetreuer folgenden Grundsatz beherzigen: Auf dem Hyper-V-Server sollten keine zusätzlichen Applikationen, Rollen, Features oder Dienste installiert werden.

Ausnahmen bestätigen allerdings die Regel. Etwa wenn ein hyperkonvergenter IT-Ansatz zum Einsatz kommt: Denn hierbei werden auf den Servern zunächst die entsprechenden Softwarekomponenten (beispielsweise Omnicube von Simplivity, SANsymphony von Datacore) installiert, und darauf die entsprechenden Hypervisoren. Auch der „Vorreiter“ Nutanix verfolgt dieses Konzept mit seinen Appliances. Der Vorteil hierbei im Backup-Bereich ist zudem die Tatsache, dass bei diesen Lösungen (oftmals) eine komplette Deduplizierung der Daten durchgeführt wird. Derartige Lösungen haben auch meist eine Backup-Lösung integriert.

Abgesehen davon werden nur die jeweiligen Anforderungen für das Virtualisierungs-Konzept auf den Hyper-V-Systemen aufgespielt. Beispielsweise der „iSCSI-Initiator“ wenn VM-Speicherplatz per iSCSI-MIPO angebunden ist. Auf keinen Fall sollten Dienstprogramme, Konfigurations-Tools, oder weitere Rollen wie etwa AD-Domaincontroller-Dienste, oder Fileserverfunktionen auf dem Hyper-V (nativ) installiert werden. Diese Rollen, Dienste und Funktionen finden innerhalb der VMs ihren Platz. Wenn weitere Funktionen auf einem nativen „serverblech“ benötigt werden, sollte ein zusätzliches System beschafft werden. Viele Systembetreuer setzen beispielsweise einen „kleinen“ Windows-Standard-Server als „Arbeitsstation“ für grundliegende Konfigurations-Arbeiten oder bestimmte Management-Tools ein.

Unterschiedliche IT-Lösungen benötigen unterschiedliche Sicherungs-Strategien

Die vorangegangenen Punkte machen folgendes klar: Die allgemeingültige, perfekte Vorlage für eine optimale Backup- und Wiederherstellungs-Strategie gibt es nicht. Vielmehr müssen sich die Systembetreuer „ihre“ IT aus unterschiedlichen Blickwinkeln betrachten. Gegebenenfalls kann es sinnvoll sein, bestimmte Änderungen vorzunehmen, und auf diese Art das Backup und die Datenwiederherstellung zu vereinfachen. Ansonsten ist es in der aktuellen Bedrohungslage durch Erpressungstrojaner ratsam, mindestens ein aktuelles „Offline-Backup“ in der Hinterhand zu haben.

Sollten die Administratoren „ihre“ IT über sehr schnelle Internetleitungen angebunden haben, kann mit der Cloud unter Umständen ein zusätzlicher „Standort“ für weitere Backup-Datensätze gewonnen werden. Dies ist etwa gut geeignet, wenn das Unternehmen nur an einem Standort ansässig ist, und die Backup-Infrastruktur im selben Gebäude untergebracht ist. Bei einem Brand- oder Wasserschaden könnte ja die komplette IT samt der Backup-Lösung beeinträchtigt werden. Dem können die Systembetreuer durch ein zusätzliches Cloud-Backup vorbeugen.

Auch wenn oftmals davon gesprochen wird, dass die Zeit für das „Magnetband“ abgelaufen ist, werden diese Lösungen als Offline-Medium nun wieder salonfähig. Besonders wenn das Unternehmen die Daten schreibgeschützt aufbewahren muss. Denn dann kommen bei den meisten Bandsystemen (oder auch beim RDX) die sogenannten „WORM-Medien“ (Write Once Read Many) als eine günstige und effiziente Lösung ins Spiel. WORM-Medien würden auch dem gefürchteten Erpressungstrojaner „einen Strich durch die Rechnung“ machen. Ebenfalls günstig ist der Einsatz von unterschiedlichen externen Laufwerken. Man spricht hierbei von einem Medien-Mix. Etwa wenn Datensicherungen sowohl auf die Netzlaufwerke, externe Festplatten und Cloud-Dienste vorgenommen werden. So erhöht sich die Sicherheit der Daten deutlich.

Zum einen sich die Hyper-V-Systeme ähnlich wie „klassische“ Server behandelt. Die Systembetreuer sorgen für ein Komplettbackup des Systems, der Nutzdaten (VMs), und spielen das System komplett zurück, wenn Probleme auftreten. Zum anderen lassen sich – aufgrund der Trennung von Hypervisor und VMs – bei Bedarf nur die VM-Container sichern. Der Hypervisor bleibt dabei außen vor. Denn dieser kann doch (meist) schnell und effizient neu installiert werden. Dies ist vor allem der Fall, wenn die Systembetreuer für diesen Fall vorbauen, und sämtliche Konfigurationsparameter in einem Skript festlegen. So muss nur neu Installiert, die VM-Container verfügbar gemacht, und das entsprechende Skript ausgeführt werden.

Um nochmals auf die Einstiegfrage in diesem Teil der Beitragsreihe zurückzukommen: Ja unter Umständen kann es sinnvoll sein, das Backup einzig auf die VM-Container zu konzentrieren, und die Hypervisor außen vor zu lassen. Lassen sich doch diese (meist) schnell und einfach auf einem neuen System bereitstellen. Bei all diesen Überlegungen darf eins nicht vergessen werden: Jede Datensicherung ist nur dann gut, wenn die Rücksicherung einwandfrei möglich ist. Um dies sicherzustellen, müssen alle Sicherungskonzepte durch entsprechende Testläufe verifiziert werden. Auf diese Weise geht den Systembetreuern der Restore zudem schnell von der Hand, wenn der Notfall eintritt.

Florian Huttenloher