Vor einiger Zeit hatte ich die Aufgabe ein Backup-Konzept für einen ESXi-Server umzusetzen. Zur Verfügung dazu stand mir der Server selbst und Speicherplatz, welcher via FTP angesprochen werden kann.
In Verbindung mit ESX(i) habe ich zum Sichern der virtuellen Maschinen natürlich auf ghettoVCB zurückgegriffen, ein simples Script aus der Community rund um Vmware und ESXi:
This script performs backups of virtual machines residing on ESX(i) 3.5/4.x+/5.x servers using methodology similar to VMware’s VCB tool. The script takes snapshots of live running virtual machines, backs up the master VMDK(s) and then upon completion, deletes the snapshot until the next backup. The only caveat is that it utilizes resources available to the Service Console of the ESX server or Busybox Console (Tech Support Mode) of the ESXi server running the backups as opposed to following the traditional method of offloading virtual machine backups through a VCB proxy.
Das Script entspricht also einer freien Variante des VCB Tools von Vmware. Gesichert wird, indem das Script zuerst einen Snapshot der entsprechenden Maschine auslöst und diesen dann weg kopiert und wieder löscht. Somit wird die zu sichernde Maschine weder in ihrer Performance noch im Betrieb gestört oder beeinträchtigt. Hier zeigt sich auch schon der unschlagbare Vorteil von einem Backup auf der Ebene vom Virtualisierungsserver!
Eingerichtet ist das ganze relativ schnell und unkompliziert, die entsprechenden Dateien gibt es von github. Als einzige aus dem Archiv wird die Datei ghettoVCB.sh benötigt, welche auch auf den ESX kopiert werden muss. Hier gilt zu beachten, die Datei sollte auf dem datastore abgelegt werden, da alle anderen Dateien nach einem Reboot nicht mehr verfügbar sind… Und fragt mich ja nicht nach dem Sinn dahinter!
Konfiguriert wird das ganze über die ersten paar Zeilen der Datei. Hier kann zum Beispiel eingestellt werden, wohin gesichert wird, wie viele Sicherungen behalten werden, ob die VM’s dafür heruntergefahren werden sollen und noch ganz viel mehr. Schaut euch dazu am besten mal unter diesem Link den Punkt “Configurations” an, da wird alles verständlich erklärt. Meine Konfiguration sieht so aus:
# directory that all VM backups should go (e.g. /vmfs/volumes/SAN_LUN1/mybackupdir)
VM_BACKUP_VOLUME=/vmfs/volumes/datastore1/backup/
# Format output of VMDK backup
# zeroedthick
# 2gbsparse
# thin
# eagerzeroedthick
DISK_BACKUP_FORMAT=thin
# Number of backups for a given VM before deleting
VM_BACKUP_ROTATION_COUNT=1
# Shutdown guestOS prior to running backups and power them back on afterwards
# This feature assumes VMware Tools are installed, else they will not power down and loop forever
# 1=on, 0 =off
POWER_VM_DOWN_BEFORE_BACKUP=0
# enable shutdown code 1=on, 0 = off
ENABLE_HARD_POWER_OFF=0
# if the above flag "ENABLE_HARD_POWER_OFF "is set to 1, then will look at this flag which is the # of iterations
# the script will wait before executing a hard power off, this will be a multiple of 60seconds
# (e.g) = 3, which means this will wait up to 180seconds (3min) before it just powers off the VM
ITER_TO_WAIT_SHUTDOWN=3
# Number of iterations the script will wait before giving up on powering down the VM and ignoring it for backup
# this will be a multiple of 60 (e.g) = 5, which means this will wait up to 300secs (5min) before it gives up
POWER_DOWN_TIMEOUT=5
# enable compression with gzip+tar 1=on, 0=off
ENABLE_COMPRESSION=0
############################
####### NEW PARAMS #########
############################
# Disk adapter type: buslogic, lsilogic or ide
ADAPTER_FORMAT=buslogic
# Include VMs memory when taking snapshot
VM_SNAPSHOT_MEMORY=1
# Quiesce VM when taking snapshot (requires VMware Tools to be installed)
VM_SNAPSHOT_QUIESCE=0
##########################################################
# NON-PERSISTENT NFS-BACKUP ONLY
#
# ENABLE NON PERSISTENT NFS BACKUP 1=on, 0=off
ENABLE_NON_PERSISTENT_NFS=0
# umount NFS datastore after backup is complete 1=yes, 0=no
UNMOUNT_NFS=0
# IP Address of NFS Server
NFS_SERVER=172.51.0.192
# Path of exported folder residing on NFS Server (e.g. /some/mount/point )
NFS_MOUNT=/upload
# Non-persistent NFS datastore display name of choice
NFS_LOCAL_NAME=backup
# Name of backup directory for VMs residing on the NFS volume
NFS_VM_BACKUP_DIR=mybackups
############################
######### EMAIL ############
############################
# Email debug 1=yes, 0=no
EMAIL_DEBUG=0
# Email log 1=yes, 0=no
EMAIL_LOG=0
# Email SMTP server
EMAIL_SERVER=auroa.primp-industries.com
# Email SMTP server port
EMAIL_SERVER_PORT=25
# Email FROM
EMAIL_FROM=root@ghettoVCB
# Email RCPT
EMAIL_TO=auroa@primp-industries.com
Ist das Backup konfiguriert, so habe ich mir noch eine weitere Datei angelegt, welche die Namen aller Maschinen enthält, welche ich gerne sichern möchte. Einfach pro Zeile der Name einer VM und gut ist’s:
./backup # cat maschines_to_backup.txt
MACHINE1
MACHINE2
MACHINE5
MACHINE7
Nun kann man das Backup theoretisch schon starten. Einfach den folgenden Befehl verwenden:
./ghettoVCB.sh -f maschines_to_backup.txt
Doch was ist ein Backup schon, wenn man es manuell anschieben muss… Ausserdem sollte das Backup ja irgendwann auch noch auf den FTP verschoben werden. Also weiter im Programm.
Leider ist die FTP-Funktionalität vom ESXi sehr stark eingeschränkt. So etwas ähnliches wie rekursives Hochladen gibt es nicht. Auch das Erstellen von Ordnern auf dem ESXi ist so nicht möglich! Diese beiden Punkte und die Tatsache, dass ein Backupvolumen von über 50GB in einem komprimierten Archiv nur noch knapp 15GB gross ist, haben mich dazu bewegt zuerst alles mit tar zu packen und dann hochzuladen. Ich weiss: Schande auf mein Haupt, die ersten Stimmen werden schon laut werden, dass ein Backup niemals gepackt werden darf. Aber, da immer das letzte Backup noch auf dem ESXi selbst liegen bleibt, gibt es noch eine zusätzliche Sicherheit und ich konnte mich zu dem Schritt überwinden.
Also entstand noch ein weiteres, recht skurriles Skript. Aber es tut seinen Zweck:
/vmfs/volumes/datastore1/backup/ghettoVCB.sh -f /vmfs/volumes/datastore1/backup/maschines_to_backup.txt >> /vmfs/volumes/datastore1/backup/log/`date +"%d"-"%m"-"%y"`.log
date=$(`echo date +%F`).tar.gz
tar -cvz -f /vmfs/volumes/datastore1/backup/$date /vmfs/volumes/datastore1/backup/*
ftpput -u USER -p PASSWORD -P FTP_SERVER_IP /$date /vmfs/volumes/datastore1/backup/$date
rm /vmfs/volumes/datastore1/backup/$date
Das Script löst zuerst das Backup aus und schreibt auch gleich ein Log dazu. Danach wird alles in ein Archiv mit dem aktuellen Datum gepackt und via FTP hochgeladen. Ja, ich weiss, FTP ist nicht wirklich das beste Protokoll dazu. Es ist zwar schnell, jedoch bricht die Verbindung einmal ab, kann diese nicht wieder aufgenommen werden, sondern muss neu beginnen. Jedoch ist FTP der einzigste Zugriffsweg, den ich habe.
Nun, damit auch noch alles automatisch abläuft, wird das Backup in den Crontab integriert. Dazu fügen wir eine weitere Zeile an:
./backup # cat /var/spool/cron/crontabs/root
#syntax : minute hour day month dayofweek command
01 01 * * * /sbin/tmpwatch.sh
01 * * * * /sbin/auto-backup.sh #first minute of every hour (run every hour)
00 22 * * * /vmfs/volumes/datastore1/backup/daily.sh
Nun muss noch ein bisschen nacharbeit geleistet werden, damit alles reibungslos abläuft:
kill $(cat /var/run/crond.pid)
crond
Damit das Konzept auch noch einen Reboot überlebt, muss noch die /etc/rc.local ergänzt werden:
/bin/kill $(cat /var/run/crond.pid)
echo "00 22 * * * /vmfs/volumes/datastore1/backup/daily.sh" >> /var/spool/cron/crontabs/root
crond
Und somit wäre eine einfache und schnelle Backuplösung für die freie Version von Vmware’s ESX implementiert.
Muss eine Maschine innert einem Backupzyklus wiederhergestellt werden, so geschieht dies direkt ab dem ESXi selbst, da das letzte Backup da immer zwischengespeichert ist. Ansonsten kann ein beliebiger Zeitpunkt vom FTP heruntergeladen, entpackt und gestartet werden. Und mit der passenden Software kann auch das Disk-Format von Vmware geöffnet und so einzelne Dateien wiederhergestellt werden.
Das könnte dich auch interessieren:
- Vmware Image für ESXi aufbereiten Für eine Analyse gab es diese Woche eine Installation von...
