Sicherungen auf Host- oder Gastebene beim Hyper-V

Wer die Hyper-V-Plattform mit Windows Server Backup (zu deutsch: Windows Server-Sicherung) sichern möchte, der sollte sich genau überlegen, ob er auf Host- oder auf Gastebene die Sicherung ausführen möchte. Vor allem bei den Wiederherstellungen gibt es dabei Einschränkungen zu beachten. Zudem darf der Snapshot-Mechanismus nicht als Backup-Ersatz missbraucht werden. Produkte von Drittherstellern wie Veeam oder Acronis aber auch Microsofts Data Protection Manager bieten ein Plus an Funktionalität.

Das Sichern und Wiederherstellen von Daten in herkömmlichen physischen IT-Infrastrukturen sollte mittlerweile keinem Administrator mehr Probleme bereiten. Die Konzepte für diese Aktionen sind bekannt und mittlerweile sollte auch jedermann wissen, dass sich die Qualität eines Backup erst dann bewerten lässt, wenn man auch den Wiederherstellungsvorgang korrekt und fehlerfrei absolviert. Doch wenn es um die Sicherung und Wiederherstellung von virtuellen Infrastrukturen – die ja immer auch auf einem physischen System laufen – geht, wird die Angelegenheit doch deutlich komplexer.

Wer auf Microsofts Server-Virtualisierungs-Plattform Hyper-V setzt, der hat vom Prinzip her die Wahl zwischen einer Sicherung auf Host-Ebene, sprich dem physischen Server, und dem Backup auf der Ebene der Gastsysteme (Virtuellen Maschinen, VMs). Beim Host-Level-Backup handelt es sich um eine Sicherung, die von der „Parent Partition“ des Hyper-V ausgeführt wird. Diese Parent Partition ist vom Prinzip her auch nur eine virtuelle Maschine, doch sie wickelt normalerweise die gesamte Ein-Ausgabeaktivitäten ab. Dabei werden beim Host-Level-Backup das Betriebssystem des Hosts sowie alle darauf liegenden VMs gesichert.

Host-Level Backup verspricht Vorteile

Dieser Ansatz besticht aufgrund von zwei Vorteilen: Zum einen ist es die einfachste Methode für ein Backup: Es lassen sich alle VMs auf dem System – egal ob sie aktiv sind oder einfach nur als VHD-Dateien auf ihren Start warten – damit sichern. Zum anderen kommen auch Kostenvorteile ins Spiel. Je nachdem welche Sicherungs-Lösung zum Einsatz kommt, benötigt man keine Agents in den VMs – und spart sich somit eventuell anfallende Lizenzkosten für diese Art von Software. Des Weiteren fallen dann auch in den VMs keinerlei Software-Verteilungs- und Verwaltungsaktionen an, etwa um die Agent-Software in die VMs zu installieren oder sie auf den neuesten Release-Stand zu bringen.

Wir dagegen die Sicherung auf der Ebene der Gastbetriebssysteme ausgeführt – also in den einzelnen VMs, wird die Angelegenheit komplexer. Andererseits bekommt der Administrator damit einen anderen Vorteil: Die Backups lassen sich feingliedriger – sprich granularer – ausführen. Denn beim Host Level Backup erfolgt die Sicherung einer VM in den meisten Fällen als ein Ganzes (also die gesamte VM-Datei). Dagegen lassen sich bei den Sicherungen auf der Ebene der VMs auch einzelne Datei aus einer Sicherung ausschließen, die man nicht sichern möchte.

Wer auf der Host-Ebene seine Backups durchführen möchte, der kann das im Lieferumfang von Windows Server 2008 enthaltene Windows Server Backup (Windows Server-Siherung) verwenden. Damit lassen sich dann die Betriebssystem-Plattform auf dem Host sowie alle VMs, die auf dem Host liegen, zusammen mit den Konfigurationsdaten sichern. Mit einbezogen werden auch eventuell vorhandene Snapshots der VMs. Dabei greift das Programm auf die Technik des VSS (Volume Shadow Copy Services) zurück.

Damit wird sichergestellt, dass die einzelnen VMs am Laufen bleiben können und dennoch eine konsistente Sicherung erfolgt, denn die VSS kümmern sich darum, dass alle „ausstehenden Aktivitäten“ der betreffenden Applikation und des zugehörigen Windows-Betriebssystems (in der Regel Schreibvorgänge auf die Festplatte) auch ausgeführt werden.

Doch dieser Ansatz hat auch Schattenseiten zu vermelden. Bei den VSS handelt es sich um eine Microsoft-Technologie – und die wird von anderen Betriebssystem-Plattformen wie Linux nicht unterstützt. Damit kann es dann zu einem nicht konsistenten Backup der VMs kommen, die nicht aus dem Haus Microsoft stammen.

Damit Windows Server Backup seine Sicherungsaufgaben durchführen kann, müssen zudem die Integrationsdienste in der zu sichernden VM installiert sein – und dabei muss die „Backup-Funktionalität“ (sie ist eine der Funktionen, die sich via Checkbox im grafischen Interface ab- oder anschalten lassen) der Integrationsdienste explizit vorhanden sein.

Eine weitere Voraussetzung für das Sichern der VMs ist deren Dateisystemtypus. Es müssen NTFS-Volumes zum Einsatz kommen – FAT16 oder FAT32 zum Beispiel finden keine Unterstützung durch Windows Server Backup.

Nachkonfiguration der virtuellen Netzwerke bringt Zusatzaufwand

Bei der Wiederherstellung von VMs, die mit Windows Server Backup gespeichert wurden, kann der Administrator böse Überraschungen erleben: Denn das Tool sichert die virtuelle Netzwerk-Konfiguration nicht mit. Beim Wiederherstellen muss der Systembetreuer daher diese Sache von Hand nachjustieren – doch dazu muss er die Informationen zuvor genau dokumentiert haben.

Weitere Einschränkungen beim Wiederherstellen beziehen sich auf die Einheiten, die sich wiederherstellen lassen: Der Administrator kann eine komplette VM wiederherstellen, doch einzelne  Dateien, Verzeichnisse oder Applikationen in einer einzelnen VM schafft diese Software nicht.

Backup auf der Ebene der Gastsysteme

Bei den Sicherungskonzepten, die auf der Basis der VMs ansetzen und einzelne VMs mit den kompletten Gastbetriebssystem, Einstellungen und Applikationen als eine Einheit sichern, stimmt die Analogie weitgehend mit dem Sichern eines einzelnen physischen Servers. Doch da ja üblicherweise mehrere VMs auf dem Virtualisierungs-Host gleichzeitig aktiv sind, muss man den Ressourcen-Verbrauch durch mehrere – gleichzeitige – Backup-Läufe mit in seine Überlegungen einbeziehen.

Eine Sicherung hat zur Folge, dass die Ein-Ausgabelast auf einem System steigt: Es sind jede Menge Lesevorgänge auf die Festplatten nötig und zudem wird auch noch Netzwerk-Bandbreite konsumiert, wenn das Backup über das Netzwerk „weg geschrieben“ werden muss. Im Normalbetrieb sind die Lasten durch mehrere VMs auf einem physischen Server gut angepasst. Doch wenn gleich mehrere Sicherungsläufe gleichzeitig agieren, dann kann es zu einer Überlastsituation für die Hardware kommen – mit all seinen negativen Folgen auf andere VMs auf dem Host.

Kompatibilitätsfragen sind zu lösen

Eine weitere Problematik beim direkten Sichern aus den VMs kommt mit der Kompatibilitätsfrage ins Spiel. VMs kommunizieren mit der darunterliegenden Hardware auf eine eigene Art: Sind die Integrationsdienste im Gastbetriebssystem installiert, sprich man von einem „enlightened“ Gastsystem. Dabei finden die Integrationsdienste als eine Art Sammlung von Treiber-Software, die eine Kommunikation der Gastbetriebssysteme mit den Hardware-Modulen erlauben. Sind keine Integrationsdienste installiert, muss über eine spezielle Emulation die Verbindung zur Hardware hergestellt werden – doch das kostet Zeit.

Doch in den beiden Szenarien gewährt die Virtualisierungsschicht – also der Hyper-V – nur den Zugriff auf einige grundlegende Server-Module. Dazu gehören optische Laufwerke (wie DVD-Drives), Netzwerkkarten oder auch CPU-Kerne. Soll dagegen USB- oder PCI-basierte Sicherungs-Hardware zum Einsatz kommen, stehen derartige Komponenten meistens für die Gastsysteme auf einem Hyper-V nicht zur Verfügung. Wer daher auf Nummer Sicher gehen möchte, er sollte die Sicherungen auf Ebene der Gastsysteme vom Windows Server Backup beim Hyper-V immer auf eine Sicherungs-Hardware ablegen, die über das Netzwerk angebunden ist.

Eine weitere Einschränkung bei der Sicherung von Gastsystemen ist der Umfang der gesicherten Daten. In üblichen Sicherungs-Szenarien ist das Weglassen von bestimmten Daten bei der Sicherung ein vernünftiger Ansatz – etwa das Ausschließen von temporären Dateien beim Backup. Bei einer Sicherung auf der Ebene des Gastsystems weiß oftmals die Sicherungssoftware nicht, dass eine VM gesichert wird. Sprich sie behandelt die VM genauso, als würde sie auf einem normalen System – ohne Virtualisierungsschicht – zum Einsatz kommen. Daher überspringt sie alle speziellen Informationen, die zur Virtualisierungs-Infrastruktur gehören.

Wenn man sich diesen Aspekt genauer ansieht, wird schnell klar: Die Sicherungs-Software schreibt die Inhalte der VHD weg, doch die Konfiguration der VM wird nicht mitgesichert. Das bedeutet, dass Sicherungen auf der Ebene der Gastsysteme sich hervorragend dazu eignen, Daten sehr feingliedrig wiederherzustellen. Doch man kann eine derartige Sicherung dann nicht verwenden, um die VM als ein Ganzes wiederherzustellen.

Wer eine komplette VM aus einer Sicherung mit Windows Server Backup auf Gastsystem-Ebene wiederherstellen muss, der hat Handarbeit zu verrichten. Zuerst muss er eine neue VM von Hand anlegen und konfigurieren – sofern die wiederherzustellende nicht mehr existiert. Dann kann man eine komplette Systemwiederherstellung in diese VM einspielen – ganz so als würde man eine Wiederherstellung auf einer „blanken Server-Hardware“ ausführen.

Doch bei einer derartigen Konstellation darf man eines nicht vergessen: Sollte eine Katastrophe passiert sein und ein kompletter physischer Server ausgefallen sein, so reicht die Sicherung aller VMs nicht: Denn die Virtualisierungsschicht selbst ist dann ja noch nicht gesichert. Dazu müsste man auch noch den Hyper-V-Host gesichert haben.

Snapshots und das Backup

Ein weiterer Aspekt bei der Sicherung von virtuellen Infrastrukturen ist das Thema Snapshots. Wird mit Windows Server Backup eine Sicherung auf der Gastsystem-Ebene ausgeführt, sind die eventuell vorhandenen Snapshots der VM nicht mit enthalten. Auch wenn diese Snapshots als eine Art von „differenzierender Festplatte“ vorliegen, so kennt sie das Gastbetriebssystem nicht und Windows Server Backup im Gastsystem sichert sie daher auch nicht.

Mit dem Snapshot-Mechanismus gibt es beim Hyper-V für die VMs eine recht elegante Methodik, um einen Zustand „einzufrieren“, ehe man eine Änderung an der Konfiguration ausführt. Schlägt bei dieser Umkonfigurierung etwas fehl, kann man recht schnell wieder auf den vorherigen Zustand zum Zeitpunkt des Snapshot zurückkommen – das sogenannte Rollback. Doch diesen Prozess sollte man nicht planlos, sondern mit viel Vorsicht verwenden.

Denn bei einem Snapshot handelt es sich um keine komplette Sicherung des Systems. Ein Snapshot bleibt immer innerhalb des Hyper-V-Servers: Falls das Laufwerk, auf dem die Snapshots liegen, ausfällt, kann man die Snapshots nicht mehr dazu verwenden, um zum vorherigen Zustand zurück zu kommen. Ein weiterer Grund für den sparsamen Umgang mit Snapshots ist das Thema Performance: Jeder Snapshot stellt hohe Anforderungen an das System in der VM. Ein Snapshot basiert auf demselben Prinzip wie eine differenzierende Festplatte: Mit jedem Anlegen eines Snapshots erzeugt man einen speziellen Typus einer virtuellen Festplattendatei. Alle weiteren Schreibzugriffe werden auf diese Datei ausgeführt und nicht auf die ursprüngliche VHD. Durch diesen Kunstgriff wird sichergestellt, dass die ursprünglichen Inhalte unverändert bleiben.

Daraus ergibt sich dann die Auswirkung bei den Lesezugriffen: Bei einem Lesezugriff nach einem Snapshot, durchsucht der Hyper-V zunächst die differenzierende Festplatte, denn sie enthält ja die aktuellsten Daten. Liegen die gewünschten Informationen nicht in dieser Datei, wendet sich der Hyper-V an die ursprüngliche Datei. Daraus lässt sich schon die reduzierte Performance ablesen, die daraus resultiert – vor allem, wenn man gleich mehrere Snapshots angelegt hat.

Für den reduzierten Einsatz von Snapshot spricht noch ein weiteres Argument: das Zusammenspiel mit den verschiedenen Applikationen. Als prinzipielle Aussage findet man bei Microsoft den Hinweis, dass Snapshots gut zu verwenden sind, wenn auf dem System (also in der VM) eine relativ statische Applikation zum Einsatz kommt. Dagegen gibt es bei dem Rollback immer potenzielle Probleme mit Anwendungen, die auf Datenbanken basieren. Besonders gefährlich sind dabei Domänencontroller mit dem Active-Directory-Datenbank. Aber auch bei Applikationen wie dem Exchange Server kann es damit zu massiven Problemsituationen kommen.

Daher scheint es derzeit als eine gute Empfehlung, für das Sichern von virtuellen Infrastrukturen auf der Basis des Hyper-V mit einer speziellen Sicherungslösung zu arbeiten. Dazu gibt es bei Microsoft den Data Protection Manager (DPM) im Rahmen der Systemcenter-Produktfamilie. Aber auch Veeam mit dem „Backup & Replication 6“ (siehe Test des Tools Veeam Backup & Recovery 6, mit der Version 6 sichert Veeam nicht nur virtuelle Maschinen von VMware, die Backup-Applikation unterstützt jetzt auch Microsoft Hyper-V) oder Acronis Backup & Recovery 11.0 (siehe Print-Ausgabe NT4ADMINS April 2012) gelten dabei als passende Kandidaten.

Rainer Huttenloher