VMware hat mit dem ESXi-Server eine Abwandlung des bekannten ESX-Servers herausgebracht. Der wesentliche Unterschied zwischen ESXi und ESX besteht darin, dass bei dem erstgenannten die so genannte Servicekonsole fehlt. Dies hat Vor- und Nachteile. Ein Vorteil ist mit Sicherheit, dass der wesentlich schlankere ESXi-Server weniger gepatcht werden muss als sein großer Bruder. Das Fehlen der Servicekonsole erkauft man sich allerdings auch mit einer eingeschränkten Flexibilität. Treiber für zusätzliche Hardware oder auch Cronjobs sind mit ESXi schwieriger zu realisieren als mit ESX.

Kaum jemand weiß, dass es den ESXi in zwei Varianten gibt. Die frei zugängliche Version kann nur “standalone” betrieben werden. Will man mehrere ESXi-Server mit dem vCenter zentral verwalten, kommt man um den Kauf einer ESXi-Lizenz nicht herum.

In diesem Artikel sollen beleuchtet werden, welche Möglichkeiten es gibt, die virtuellen Maschinen auf einem einzeln stehenden ESXi-Server zu sichern. VMware verbietet Anbietern kommerzieller Backup-Lösungen, Sicherungen von virtuellen Maschinen auf solchen Hosts zu ermöglichen.

Auch beim Betrieb von virtuellen Maschinen ändern sich die grundlegenden Fragen, die man sich bei der Bereitstellung einer Backup-Lösung stellt, nicht. Ein Backup sollte so oft wie möglich, so zuverlässig wie möglich und automatisch stattfinden. Das Backup sollte räumlich getrennt von den Produktivsystemen erstellt werden, und die Produktivsysteme dürfen durch das Backup in ihrer Funktion nicht beeinträchigt werden. Eine Wiederherstellung, vollständig oder auch nur partiell, muss einfach sein. Ebenso einfach sollte die Erweiterung des Backup-Konzeptes sein.

Es folgt die Beschreibung der absoluten Low-Cost-Variante für virtuelle Maschinen auf ESXi-Hosts. Die räumliche Trennung erreicht man durch den Einbau einer zusätzlichen Festplatte in den ESXi-Host. Auf dieser Platte werden nur Backups gespeichert.

Das frei verfügbare Backup-Script Ghettovcb besteht aus zwei Dateien: zum einen aus dem eigentlichen Script, das nur wenige Einstellungen erfordert. In einer zweiten, reinen Textdatei werden alle zu sichernden virtuellen Maschinen aufgelistet. Somit ist auch eine einfache Erweiterbarkeit gewährleistet. Sobald eine neue VM gesichert werden soll, wird einfach die Textdatei um eine Zeile erweitert.

Ghettovcb funktioniert, wie übrigens alle Systeme, die virtuelle Maschinen sichern, nach dem folgenden Prinzip: Zunächst wird ein Snapshot der VM erstellt, das heißt, die aktuelle VMDK-Datei wird “eingefroren” und alle Änderungen ab dem Zeitpunkt des Snapshots fließen in eine Delta-Datei. Somit ist ein einfaches Kopieren der VMDK-Datei im laufenden Betrieb möglich. Die Anforderung der Nichtbeeinträchtigung von Produktivsystemen ist somit auch erfüllt.

In den Ghettovcb-Einstellungen kann definiert werden, wie viele Backup-Versionen vorgehalten werden sollen.Es ist also möglich, immer eine gewisse Zahl von Sicherungen vorzuhalten. Bei einer erfolgreichen Sicherung löscht Ghettovcb die älteste vorhandene Sicherung.

Die automatische Ausführung des Backup-Scriptes ist zum Beispiel mit Plink möglich. Auf einer virtuellen Maschine wird einfach ein geplanter Task eingerichtet, der Ghettovcb so oft wie gewünscht mittels Plink anstößt. Funktioniert das erst einmal, ist auch die Anforderung nach Automatisierung erfüllt.

Die Wiederherstellung einer mit Ghettovcb gesicherten VM ist denkbar einfach. Die Dateien (VMX, VMDK, …) aus dem Sicherungsverzeichnis werden einfach zurückkopiert, die VM wird registriert und eingeschaltet. Auch einzelne Dateien können durch das Mounten der VMDK-Datei, zum Beispiel mit UFS Explorer oder Winimage zurückgespielt werden.

Persönlich kann ich nur Positives über das beschriebene Backup-Konzept berichten. Es funktioniert zuverlässig und ist vollkommen transparent. Sicher ist die Verwendung einer zusätzlichen Festplatte im gleichen Host nur eine Kompromisslösung. Dafür geht die Sicherung aber sehr schnell. Wer über GBit-Netzwerk verfügt, kann auch auf einen räumlich entfernten NFS-Store sichern.