VMware Backup Varianten: ghettoVCBg2.pl
Für Kommandozeilen und Perl-affine Administratoren ist der Virtual Management Assistant (vMA) von VMware die ideale Schaltzentrale. Aber nicht nur das – er stellt er auch die Mittel für ein kostengünstiges, zentralisiertes Backup bereit, welches zwar nicht allen, aber vielen Anforderungsprofilen (speziell in kleineren Umgebungen) genügen kann. Nehmen wir zur Übersicht einen kurzen Schritt zurück.
Kommerzielle Backup-Lösungen
Virtualisierung ermöglicht bekannterweise neue Methoden der Datensicherung, z.B. die Komplettsicherung von virtuellen Maschinen. Das ist praktisch für Desaster-Recovery-Zwecke, bringt aber auch seine eigenen Herausforderungen mit sich: Wie sichert man eine laufende virtuelle Maschine ohne Downtime? Wie geht man intelligent mit den anfallenden Datenmengen um? Wie stellt man einzelne Dateien aus gesicherten virtuellen Maschinen wieder her?
Neben Agenten für gängige Backup-Lösungen (NetBackup, Legato, …) füllen diese Nische spezialisierte Lösungen wie Vizioncore vRanger Pro, Veeam Backup & Replication oder PHD Virtual esXpress. Zum Funktionsumfang gehören dabei meist
- eine zentrale GUI zum Verwalten der Backup-Jobs
- Deduplizierung auf Blockebene bzw. Komprimierung, um anfallende Sicherungsmengen zu reduzieren
- inkrementelle VM-Sicherungen
- Rücksicherung von einzelnen Dateien aus VM-Vollbackups
- oder aber Replikation zum Zwecke von Continuous Data Protection (CDP).
Kostenfrei: ghettoVCBg2.pl
Für virtuelle Infrastrukturen mit weniger ausgewachsenem Anforderungsprofil (und weniger Buzzword Bedarf) gibt es mit ghettoVCBg2.pl, der Weiterentwicklung von ghettoVCB.pl, eine kostenfreie, im Funktionsumfang reduzierte Alternative. Basierend auf dem Perl SDK nutzt es dynamisch erstellte Snapshots zum Abziehen von VM-Vollbackups – sprich: man erhält als Sicherungs-Endprodukt eine komplette Kopie der gesicherten VM, die man im Desaster-Fall auf einem anderen (oder dem wiederhergestellten) ESX Server in Betrieb nehmen kann.
Im Gegensatz zu seinem Vorgänger ist ghettoVCBg2.pl nicht mehr für den lokalen Einsatz auf einem ESX Server gedacht, sondern zum Einsatz auf dem eingangs erwähnten vMA ausgelegt. Der ermöglicht die Sicherung von VMs, ungeachtet der Frage auf welchem von mehreren potentiellen ESX Servern die VMs zum Zeitpunkt der Sicherung laufen. Was ghettoVCBg2.pl erklärterweise nicht unterstützt, ist die Sicherung von VMs mit bestehenden Snapshots. Wenn man bedenkt, welche Implikationen lang bestehende Snapshots aus betrieblicher Sicht haben (z.B. kein Storage Motion möglich) ein zu verschmerzender Sachverhalt.
Vorbereitende Arbeiten vMA / ESX Hosts
Insofern noch nicht in Betrieb, kann der VMware Virtual Management Assistant hier kostenfrei heruntergeladen werden. Diesen nimmt man in Betrieb (VM importieren und starten), loggt sich als vi-admin ein und bringt ihm initial die Credentials für das vCenter und die ESX Server bei.
$ vifp addserver <vcenter-hostname> [--username user]
$ vifp addserver <esx1-hostname> [--username user]
$ vifp addserver <esx1-hostname> [--username user]
$ vifp addserver ….
Die so hinzugefügten Server lassen sich via
$ vifp listservers
anzeigen und sind in ~/.vmware/credstore/vicredentials.xml fest hinterlegt. Perl Skripte, welche die vifp Features unterstützen (und dazu gehört ghettoVCBg2.pl) haben somit “authentifizierungs-losen” Zugriff auf die Server. Falls es beim Hinzufügen von ESX-Hosts zu Timeouts kommt, hat sich erfahrungsgemäß der hostd auf dem betroffenen Host verklemmt und muss neu gestartet werden (hier hilft VMware KB #1003490 “Restarting the Management agents on an ESX or ESXi Server” weiter).
Weiterhin empfiehlt es sich, als Zieldatenspeicher für die Sicherungen ein zentrales NAS Dateisystem auf seinen ESX Hosts zu mounten – über die GUI oder via esxcfg-nas. Das NAS Dateisystem kann von einem Enterprise-Storage (NetApp, Sun Unified Storage, etc.) oder aber auch ein OpenFiler bzw. FreeNAS kommen. Damit hat man seine Sicherungsdaten an zentraler Stelle und im Bedarf auf allen ESX Hosts verfügbar.
Konfiguration und Inbetriebnahme
Nun kann ghettoVCBg2.pl heruntergeladen und auf dem vMA abgelegt werden. Zur Konfiguration editiert man das Skript und passt im oberen Teil die folgenden Variablen entsprechend seiner individuellen Bedürfnisse an. Als Beispiel:
my $VM_BACKUP_DATASTORE = “nfs-esx-share”;
my $VM_BACKUP_DIRECTORY = “ghettoVCBg2-backup”;
my $VM_BACKUP_ROTATION_COUNT = “3″;
my $DISK_BACKUP_FORMAT = “thin”;
my $POWER_VM_DOWN_BEFORE_BACKUP = “0″;
my $VM_SNAPSHOT_MEMORY = “1″;
my $VM_SNAPSHOT_QUIESCE = “1″;
Backups werden hier auf dem Share namens “nfs-esx-share” im Ordner “ghettoVCBg2-backup” abgelegt. Es werden jeweils drei Kopien aufgehoben (Achtung: Das Rotieren geschieht erst nach erfolgtem Backup, also Platz für bis zu n + 1 Sicherungen kalkulieren) und die Sicherungen erfolgen im thin Format (siehe ESX Disk Options). Der Arbeitsspeicher der VMs wird mitgesichert und vor dem Erstellen des zur Sicherung benötigten Snapshots wird Gast-seitig ein Flushen vorhandener Dateisystem-Buffer ausgelöst (benötigt installierte VMware Tools im Gast).
Abschließend stellt man die Liste von ein paar zu sichernder Test-VMs in einer Datei mit beliebigem Namen zusammen (beispielsweise vmlist) und startet ghettoVCBg2.pl zu einem ersten Testlauf
$ ./ghettoVCBg2.pl –output /dev/stdout –vmlist vmlist
Wenn soweit alles passt, kann man diesen Aufruf mit angepasster –output Zieldatei in die crontab des vi-admin Nutzers packen und hat somit periodische Vollsicherungen seiner virtuellen Maschinen.
Ausblick
An einigen Ecken ist sicherlich noch Anpassungsaufwand notwendig: Windows VMs fühlen sich zu Sicherungszwecken mit Volume Shadow Services am wohlsten, Datenbanken oder andere Dienste wollen vor der Sicherung ggf. in einen konsistenten Zustand versetzt werden und eine Überwachung des Backup-Logs mit z.B. Nagios ist empfehlenswert.
Vieles ist denkbar, der letztendlich wichtigste Aspekt ist wie bei allen Dingen das Testen der Funktionalität für die eigene Infrastruktur (Sicherung/Rücksicherung, sonstige funktionale Anforderungen sowie betriebliche Aspekte – passt die Lösung in unsere Umgebung?) … und das gilt sowohl fŭr die kommerziellen Varianten als auch für ghettoVCBg2.pl.
Erfolgreiches Sichern!


danke für den artikel, was ich noch nicht verstehe, muss der NFS Share am ESX gemountet sein oder am vMA?
PS: es heisst vifp listservers statt listserver
Danke für den Typo-Hinweis. NFS Share ist am ESX Server zu mounten. ghettoVCBg2.pl stößt zum Sichern einen Kopierprozess auf dem ESX an, d.h. die Daten werden nicht über den vMA geschleust, sondern nur auf dem ESX von einem Datastore auf einen anderen – im konkreten Fall das NFS Share – geschaufelt.
ja danke, hat super funktioniert
schauen uns im moment auch vmware data recovery an, mit der dedup möglichkeit sehr interessant…
Hallo,
Bei mir kommt immer is using free license & can’t support VM backups!
06-09-2011 10:16:39 — info: ============================== ghettoVCBg2 LOG START ==============================
06-09-2011 10:16:39 — debug: copyTask: Task START
06-09-2011 10:16:39 — debug: copyTask: waiting for next job and sleep …
06-09-2011 10:16:39 — info: CONFIG – BACKUP_LOG_OUTPUT = /tmp/ghettoVCBg2.log
06-09-2011 10:16:39 — info: CONFIG – VM_BACKUP_DATASTORE = nasvmware
06-09-2011 10:16:39 — info: CONFIG – VM_BACKUP_DIRECTORY = BACKUPS
06-09-2011 10:16:39 — info: CONFIG – DISK_BACKUP_FORMAT = 2gbsparse
06-09-2011 10:16:39 — info: CONFIG – ADAPTER_FORMAT = buslogic
06-09-2011 10:16:39 — info: CONFIG – POWER_VM_DOWN_BEFORE_BACKUP = NO
06-09-2011 10:16:39 — info: CONFIG – VM_SNAPSHOT_MEMORY = NO
06-09-2011 10:16:39 — info: CONFIG – VM_SNAPSHOT_QUIESCE = NO
06-09-2011 10:16:39 — info: CONFIG – VM_BACKUP_DIR_NAMING_CONVENTION = 2011-06-09
06-09-2011 10:16:39 — info: CONFIG – VM_VMDK_FILES = all
06-09-2011 10:16:39 — debug: Main: Login by vi-fastpass to: abraham.vm.dom
06-09-2011 10:16:40 — warn: abraham.vm.dom is using free license & can’t support VM backups!
06-09-2011 10:16:40 — debug: Main: Disconnect from: abraham.bits2000.dom
06-09-2011 10:16:40 — error: getFinalList: ERROR – Unable to locate VM: win2003_test_1
06-09-2011 10:16:40 — debug: Main: Calling final clean up
06-09-2011 10:16:40 — debug: cleanUP: Thread clean up starting …
06-09-2011 10:16:40 — debug: cleanUp: CopyTask was never started, send copyTaskStart
06-09-2011 10:16:40 — debug: cleanUp: Send exit to copyThread
06-09-2011 10:16:40 — debug: copyTask: Wake up and follow the white rabbit, with status: exit
06-09-2011 10:16:40 — debug: copyTask: die …
06-09-2011 10:16:40 — debug: cleanUp: Join passed
06-09-2011 10:16:40 — info: ============================== ghettoVCBg2 LOG END ==============================
Hey Kay, zum Einsatz von ghettoVCBg2 muss dein ESX lizensiert sein (andernfalls erlaubt die vSphere API keinen Schreibzugriff, ergo auch kein geskriptetes Erstellen von Snapshots). Das wird bei dir wohl nicht der Fall sein, daher der Hinweis auf die Free Version. Siehe auch “ESX/ESXi Version Support Table” bzw. FAQ 1Q auf der ghettoVCBg2 Seite http://communities.vmware.com/docs/DOC-9843.
1Q: I’m using ESXi and free licensed version ( I did not pay for anyting ), will this script still work?
1A: No, you need to have a licensed version of ESXi to use this script.
Darüberhinaus kann ich nur jedem nahe legen, zu testen, wie sich ghettoVCBg2 in (umgebungsabhängig) typischen Fehlerfällen verhält – und ob nicht doch die Investition in etwas Solideres angebracht wäre. Kürzlich getestet für einen NFS Filer als Zielstorage, der mitunter mitten im Sicherungsfenster offline gehen kann. Ergebnis: ghettoVCBg2 meldet brav eine erfolgreiche Sicherung – obwohl das Backup unbrauchbar war. http://communities.vmware.com/message/1734113#1734113