Sicherung virtualisierter IT-Umgebungen
Strategien für Backup und Recovery
Virtualisierung von Server-Infrastrukturen ist zu Recht bei immer mehr Unternehmen im Einsatz, da sie eine Vielzahl von Vorteilen bietet. Allerdings hat die Umstellung von physischen auf virtualisierte Server auch Auswirkungen auf die Backup- und Recovery-Strategie. Der Beitrag zeigt Möglichkeiten auf, wie sich die Herausforderungen beim Backup und Recovery virtualisierter IT-Umgebungen meistern und bekannte Fallstricke umgehen lassen.Virtualisierung bietet Unternehmen eine höhere Auslastung der vorhandenen Server-Hardware, mehr Flexibilität und eine höhere Verfügbarkeit der Applikationen. In der Regel steigt aber die Komplexität in der Verwaltung dieser Umgebungen. Dies betrifft auch die Sicherung virtualisierter Umgebungen. Dabei gilt es, eine Reihe von Details zu beachten.
Die Grundidee bei der Sicherung von virtuellen Systemen besteht darin, über das Host-System die Gastsysteme komplett als Snapshot zu sichern. Damit erübrigt es sich, jede virtuelle Maschine mit einem zusätzlichen Backup-Agenten auszustatten. Eine Datensicherung ist daher sofort nach Aufsetzen der virtuellen Maschine (VM) möglich, da die Sicherung über den (physischen) Host zum Backup-Server erfolgt.
VMware und Citrix Xenserver liefern für ihre Virtualisierungslösungen spezielle Backup-APIs, über die ein Zugriff der Backup-Software auf die Management-Schicht des Hypervisors erfolgt. So wird das Backup der einzelnen virtuellen Maschinen unabhängig von den physischen Hosts. Es reicht, einmal eine VMware- oder Citrix-Xenserver-Farm dem Backup-Server bekannt zu machen. Neue Hosts oder virtuelle Maschinen sind darüber automatisch bei der Backup-Software regis-triert und lassen sich sichern.
Diese Möglichkeit der Sicherung von kompletten VMs im laufenden Betrieb stellt eine sehr beliebte und wirkungsvolle Backup-Strategie dar. Doch genau dort lauern die Fallstricke im Detail. Um eine Datensicherung zu starten, kommuniziert die Backup-Software mit der API des Hypervisors. Letzterer erzeugt einen Snapshot des laufenden Gastsystems und liefert diesen zusammen mit der Metainformation des Gast-Betriebssystems an die Backup-Software. Diese kann die Daten dann auf Disk oder Tape speichern. Der Snapshot wird im laufenden System erzeugt, wobei es natürlich zu keiner Unterbrechung des Betriebs der virtuellen Maschinen kommt. Auch den eventuellen Umzug einer VM von einem Host auf einen anderen während der Datensicherung stellen die APIs für die Backup-Software transparent dar.
Einschränkungen von Snapshot Backups
Diese Datensicherung über Snapshots arbeitet zwar sehr effektiv, stellt aber gleichzeitig auch eine Limitierung des Einsatzes von Backup-APIs dar. Für ein vollständiges Backup und einen möglichen Restore ist zwischen folgenden Daten zu unterscheiden:
Betriebssystem mit Treibern, Bibliotheken und Konfigurationseinstellungen,
Binaries der Applikationen, Konfigurationsdateien und statische Dateien (beispielsweise bei Web- und File-Servern) sowie
Daten aus Datenbanken und/oder Group-ware-Systemen.
Die Daten der beiden erstgenannten Typen eignen sich perfekt für die Sicherung mittels Snapshot, da diese Daten weitgehend statisch sind. Im Gegensatz dazu verhalten sich die Daten von Datenbanken und Groupware-Systemen sehr dynamisch und ändern sich ständig.
Da die Backup-API des Hypervisors nicht in der Lage ist, die Datenbank beziehungsweise das Groupware-System über den gerade ablaufenden Snapshot zu informieren, besteht die Möglichkeit, dass während dieses Zeitraums Transaktionen in der Datenbank stattfinden. Aus diesem Grund kann der Snapshot inkonsistente Daten enthalten - auf deren Basis im Bedarfsfall kein brauchbarer Restore möglich ist. Je größer die Datenbank, umso wahrscheinlicher sind inkonsistente Daten.
Die einzige Chance, in diesem Szenario ein konsistentes Backup zu erhalten, bietet der traditionelle Weg über einen Online-Client für die Datenbank beziehungsweise das Groupware-System, der im virtuellen Gastsystem installiert ist. Er erzeugt die Sicherungskopie im laufenden Betrieb und schickt sie über das LAN - und nicht über den Hypervisor - an das Sicherungsmedium.
Einen weiteren Schwachpunkt stellt der Restore einzelner Dateien dar. Die Sicherung über die Backup-API liefert einen vollständigen Snapshot des Gastsystems. Dies hat zur Folge, dass im Restore-Fall auch der gesamte Snapshot zurückgespielt werden muss, um an die Daten im Snapshot zu gelangen. In der Praxis kann dies bedeuten, dass der Administrator einen 200-GByte-Snapshot einspielen muss, um beispielsweise eine 2 MByte große Datei wiederherzustellen.
Diese Aussage relativiert sich teilweise bei der Verwendung von VMware als Hypervisor mit Windows-Gastsystemen. Geeignete Backup-Systeme wie SEP Sesam können hier über die API und eigene Logik einzelne Dateien zurücksichern. Dies gilt allerdings nur für Windows-Gastsysteme, nicht jedoch bei Linux, Unix oder Netware als Gastsystem.
Mithilfe von Microsofts Volume Shadow Copy Service (VSS) lassen sich konsistente Snapshots im laufenden Betrieb sowohl von den Gast-Betriebssystemen als auch von Datenbanken beziehungsweise Groupware-Systemen erstellen, die in den VMs laufen. Denn bevor der Snapshot erzeugt wird, friert das VSS-Kommando die Datenbank beziehungsweise das Groupware-System ein. Diese Technik funktioniert bei allen Applikationen, die VSS unterstützen.Allerdings trifft auch hier zu, dass jeweils ein Snapshot des kompletten MS-SQL- oder MS-Exchange-Servers entsteht, den der Anwender bei einem Restore wieder komplett zurücksichern muss.
Die Rücksicherung einer einzelnen, versehentlich gelöschten E?Mail oder einer einzelnen Datenbank ist dabei nicht möglich. Auch ein PiT-Restore (Point in Time Recovery) lässt sich mit dieser Methode nicht realisieren.
Da gerade Datenbanken in der Regel sehr umfangreich sind, ist ein Restore entsprechend zeitaufwändig oder bei zu wenig Speicherresourcen oft nicht praktikabel. Auch inkrementelles Backup scheidet aus - es ist immer die gesamte VM mit allen Daten zu sichern. Deshalb stellt die Snapshot-Technik für viele Szenarien im Unternehmen keine empfehlenswerte Backup- und Recovery-Methode dar.
Verteilte Umgebungen
Vor allem in Windows-Umgebungen gibt es einen weiteren Punkt zu beachten, denn immer mehr Windows-Applikationen verteilen ihre Daten auf verschiedene Server. So benötigt ein Sharepoint-System typischerweise eine Farm von drei Servern: Domain Controller, Datenbank- und Web-Server.
Ein Backup, das über die Hypervisor-API mithilfe von VSS erzeugt wird, liefert einen konsistenten Snapshot eines einzigen Servers - beispielsweise der MS-SQL-Datenbank oder des MS-Exchange-Servers. Allerdings ist dieser Snapshot nicht konsistent mit den Daten der weiteren Server - etwa dem Domain Controller. Dies führt im Fall eines Restores zu erheblichen Problemen, weil auf den unterschiedlichen Servern verschiedene Datenstände zur Verfügung stehen und sich diese nicht synchronisieren lassen, da das Backup nicht über die Schnittstelle der Datenbank erfolgte. Ähnliche Probleme können auftreten, wenn der Verzeichnisdienst Active Directory über mehrere Server verteilt ist. Bei allen geschilderten Beispielen empfiehlt sich daher die Sicherung über Backup-Clients, die eine Sicherung im laufenden Betrieb unterstützen und die direkt in den virtuellen Gästen installiert sind.
Die Sicherung über die API der verschiedenen Hypervisoren bildet eine wichtige Komponente, um die hohe Verfügbarkeit und das schnelle Disaster Recovery von virtualisierten Servern sicherzustellen. Allerdings sollte diese Methode Teil einer umfassenderen Backup- und Restore-Strategie sein. Denn gerade für die gezielte Wiederherstellung einzelner Dateien und E?Mails eignet sich diese Technik nur bedingt. Hinzu kommt, dass sie für verteilte Systeme schlichtweg nicht zu empfehlen ist, weil konsistente Sicherungen im laufenden Betrieb nicht möglich sind. Die Sicherung von E?Mail und Groupware-Systemen sowie verteilte Umgebungen erfordern die Sicherung über Backup-Clients, die auf der jeweiligen virtuellen Maschine zu installieren sind. Idealerweise unterstützt dabei die ausgewählte Backup-Software nicht nur die Sicherung der virtualisierten Server, sondern ermöglicht auch das Backup der übrigen physischen Server. So kann der Administrator die Sicherung aller Systeme aufeinander abstimmen und mit einem einzigen Tool verwalten.
Lesen Sie mehr zum Thema
