Um Backups von ESXi VMs im laufenden Zustand machen zu können, braucht es
- Verständnis was VmWare unter einem Snapshot versteht
- Das Scipt ghettoVCB.sh => ghettoVCB
Exkurs VMWare-Snapshot
Bei einem VMware Snapshot wird eine weitere Festplattendatei erstellt welche ab Zeitpunkt des Snapshots alle geänderten Blöcke aufnimmt. Gleichzeitig wird der Exklusiv Zugriff auf die Basis Festplatte aufgehoben so das andere Prozesse lesen koennen.
Dieses “lesen” kann ein Kopierbefehl einens Backupprogramms sein. Da keine Schreibzugriffe mehr in die Datei erfolgen ist der Zustand also konsistent. Snapshots sind also keine Backups. Ein Snapshot “friert” lediglich einen Zustand ein (Basis Festplatte) und schreibt alle ab diesem Zeitpunkt anfallenden Änderungen in eine neue Snapshot Datei (Delta).
- Die Basisplatte und der bzw. die Snapshots zusammen ergeben den akt. Stand. Fehlt ein Element in der Kette ist kein vollstaendiges Restore mehr moeglich. Beides muss zur gleichen Zeiten fuer den HOST zugaenglich sein.
- Snapshots wachsen bis zur max. konfigurierten Festplattengroesse heran. Die Groesse des Datastores ist also zu ueberwachen.
- Beim löeschen von mehr als 2 Snapshots ist zu bedenken das ein Helper angelegt wird und immer die Groesse der zusammen zufuehrenden Snaps benoetigt wird.
- Laufende Snaps kosten ein wenig Performance. Die Gefahr von Fragmentierierung ignorieren wir da die Snaps immer in 16MB Bloecken wachsen.
- Grosse Snaps loeschen, hier versteht VMware das einpflegen der Aenderungen, dauert lange
Beispiel:
- Basisplatte
- Snapshot1
- Snapshot2
- Snapshot3
- Snapshotx
Löscht man jetzt Snapshotx wird dieser (und damit alle davorigen Snapshots) in die Basisplatte eingepflegt.
Löscht man Snapshot2 wird dessen Zustand und der von Snapshot1 in die Basisplatte eingepflegt und Snapshot3 usw. werden zu Snapshot1 usw,
Die .VMDK-Files (Virtuell Maschine Disk Files) können im laufenden Betrieb nicht kopiert oder verschoben werden, da sie ja in Gebrauch sind. Dies sieht aber nach einem Snapshot anders aus. Bei einem Snapshot werden die .VMDK-Files im Prinzip gekappt und neue Files (VMSN und VMSD) angelegt, in welche die kompletten Änderungen des Snapshots geschrieben werden. Wenn man ein Snapshot der VM macht, wird die Basis-Festplatte in den Read-Only Modus gesetzt, wordurch diese nun, da konsisten, kopiert werden kann. Das Verhalten von Snapshots kann also ausgenutzt werden um Backups im laufenden System erstellen zu können (Hilfsmittel zum Backup):
Komplettbackup 1
- Das Konfigurations-File der VM sichern/kopieren (VMX-File)-> nach dem Snaphsot der vituellen Maschine ändern sich die Verweise in der Konfiguration.
- Man erstellt einen ersten Snapshot einer VM. Es bestehen anonsten keine Snapshots dieser VM. Der Snapshot wird also gemacht, und die Basis-Festplatte kopiert. Anschliessend den Snapshot wieder loeschen. Dieses Vorgehen benötigt entsprechend viel Platz, wenn mehrere Backups der gleichen VM notwendig sind.
Komplettbackup 2
- Man macht täglich einen Snapshot und sicherst den Snapshot des Vortages. Bedeutet weniger Platz da quasi nur Aenderungen dann noch anfallen. Aber ein Restore erfordert Knowhow und dein ESX wird mehr belastet.
Soweit der Exkurs… Um ein Backup zu erstellen, können wir das mit den Snapshots manuell machen oder aber mit dem ghettoVCB-Script arbeiten. Das macht nämlich genau das oben beschriebene.
Installation von ghettoVCB
Die Installation ist simple. Einfach ein Verzeichnis auf dem ESXi-Datastore erstellen und die ghettoVCB-Scripts hineinkopieren. Das wird ganz schön auf Youtube gezeigt: http://www.youtube.com/watch?v=mVrjxzKEEu4
ghettoVCB konfigurieren und Backup durchführen
Die Konfigurationsmölgichkeiten findet man hier: http://communities.vmware.com/docs/DOC-8760
ghettoVCB.conf File
Ich habe mein ghettoVCB.conf File folgendermassen konfiguriert (ist eingentlich alles Standard):
VM_BACKUP_VOLUME=/vmfs/volumes/65d7a6db-6bc8d65a/VmBackups
DISK_BACKUP_FORMAT=thin
VM_BACKUP_ROTATION_COUNT=1
POWER_VM_DOWN_BEFORE_BACKUP=0
ENABLE_HARD_POWER_OFF=0
ITER_TO_WAIT_SHUTDOWN=3
POWER_DOWN_TIMEOUT=5
ENABLE_COMPRESSION=0
VM_SNAPSHOT_MEMORY=0
VM_SNAPSHOT_QUIESCE=0
SNAPSHOT_TIMEOUT=15
VMs zum Backup
Habe ein File “vms_to_backup” erstellt, welches eine Liste der Namen der VMs beinhaltet. Bei den Namen handelt es sich um die Namen, welche auch im vSphereClient angezeigt werden:
TestVM32Bit
Backup run
Nun kann die VM im laufenden Zustand gebackuped werden (Option -d dryrun führt einen Testlauf durch):
./ghettoVCB.sh -f vms_to_backup -g ./ghettoVCB.conf -d dryrun
Backup automatisch durchführen (Cron-Tab)
Um das Backup automatisch durchzuführen, kann dies in der Cron-Tab von ESXi konfiguriert werden:
In Crontab registrieren, Job soll jeden Donnerstag um 17:00 Uhr durchgeführt werden
echo "0 17 * * 4 /vmfs/volumes/4a6bb65f-eb654b7b-2525-d8d385ab5bd2/ghettoVCB/ghettoVCB.sh -f /vmfs/volumes/4a6bb65f-eb654b7b-2525-d8d385ab5bd2/ghettoVCB/vms_to_backup -g /vmfs/volumes/4a6bb65f-eb654b7b-2525-d8d385ab5bd2/ghettoVCB/ghettoVCB.conf > /tmp/ghettoVCB.log" >> /var/spool/cron/crontabs/root
Wenn man dies Ausführt, wird der crontab automatisch an die richtige Datei angehängt.
Nun muss crond neu gestartet werden:
ESXi 4.1
/bin/kill $(cat /var/run/crond.pid)
/bin/busybox crond
Die Cron-Tab von ESXi wird bei jedem Start wieder neu geschrieben. Um die Zeile deswegen bei jedem Start auszuführen, muss diese noch in die /etc/rc.local eingetragen werden. Meine rc.local sieht anschliessend so aus:
vi /etc/rc.local
#! /bin/ash
export PATH=/sbin:/bin
log() {
echo "$1"
logger init "$1"
}
#execute all service retgistered in /etc/rc.local.d
if [ -d /etc/rc.local.d ]; then
for filename in `find /etc/rc.local.d/ | sort`
do
if [ -f $filename ] && [ -x $filename ]; then
log "running $filename"
$filename
fi
done
fi
/bin/kill $(cat /var/run/crond.pid)
/bin/echo "0 17 * * 4 /vmfs/volumes/4a6bb65f-eb654b7b-2525-d8d385ab5bd2/ghettoVCB/ghettoVCB.sh -f /vmfs/volumes/4a6bb65f-eb654b7b-2525-d8d385ab5bd2/ghettoVCB/vms_to_backup -g /vmfs/volumes/4a6bb65f-eb654b7b-2525-d8d385ab5bd2/ghettoVCB/ghettoVCB.conf > /tmp/ghettoVCB.log" >> /var/spool/cron/crontabs/root
crond
ESXi 5.5
kill $(cat /var/run/crond.pid)
crond
Die Cron-Tab von ESXi wird bei jedem Start wieder neu geschrieben. Um die Zeile deswegen bei jedem Start auszuführen, muss diese noch in die /etc/rc.local eingetragen werden. Meine rc.local sieht anschliessend so aus:
vi /etc/rc.local.d/local.sh
#!/bin/sh
# local configuration options
# Note: modify at your own risk! If you do/use anything in this
# script that is not part of a stable API (relying on files to be in
# specific places, specific tools, specific output, etc) there is a
# possibility you will end up with a broken system after patching or
# upgrading. Changes are not supported unless under direction of
# VMware support.
/bin/kill $(cat /var/run/crond.pid)
echo "0 17 * * 4 /vmfs/volumes/54016b12-54a601dc-1d3c-d43d7e942aae/ghettoVCB/ghettoVCB.sh -f /vmfs/volumes/54016b12-54a601dc-1d3c-d43d7e942aae/ghettoVCB/vms_to_backup -g /vmfs/volumes/54016b12-54a601dc-1d3c-d43d7e942aae/ghettoVCB/ghettoVCB.conf > /tmp/ghettoVCB.log" >> /var/spool/cron/crontabs/root
crond
exit 0
Nun nur noch autobackup durchführen, das ganze in der ESXi Konfuguration zu speichern:
/sbin/auto-backup.sh
Das wars! Jetzt werden die VMs automatisch regelmässig gesichert.
Restore durchführen
Um einen Restore druchzuführen, habe ich ein file vms_to_restore erstellt, wobei dieses pro Linie einen Restore-Parameter mit folgendem Format enthalten muss:
";;"
# DISK_FORMATS
# 1 = zeroedthick
# 2 = 2gbsparse
# 3 = thin
# 4 = eagerzeroedthick
z.B.:
"/vmfs/volumes/QnapTSDatastore/VmBackups/TestVM32Bit/TestVM32Bit-2013-01-03_13-25-54;/vmfs/volumes/ESXi Raid1/TestVM;3"
Anschliessend kann das Restore folgendermassen gestartet werden (Option -d 2 = Dryrun):
./ghettoVCB-restore.sh -c vms_to_restore -d 2
Dies stellt das von ghettoVCB erstellte Backup “TestVM32Bit-2013-01-03_13-25-54” unter dem Pfad “/vmfs/volumes/ESXi Raid1/TestVM” her bzw. kopiert diese dahin und registriert die VM neu beim ESXi-Host.
Die Fileformate
zeroedthick (default)
vmdk wird in voller Groesse angelegt – dieser Typ wird bei der Erstellung nicht mit Nullen ueberschrieben – das passiert erst spaeter im Betrieb
eagerzeroedthick
vmdk wird in voller Groesse angelegt – dieser Typ wird bei der Erstellung mit Nullen ueberschrieben
thick
vmdk wird in voller Groesse angelegt – und nie genullt
thin
vmdk waechst nach Bedarf – dies ist ein Feature des VMFS dateisystems – und ist auf den meisten NFS-servern nicht moeglich
2gbsparsed
vmdk wird in maximal 2 Gb grosse Stuecke aufgeteilt – die jeweils nach Bedarf wachsen – dieses Format ist it Workstation kompatibel