[Support]  [Forum]  [Newsletter]       [Site-Map]  [Suche]  [Kontakt]  [Impressum]

Stor IT Back - Ihr Speicherspezialist

[Angebote]   [Produkte]   [Schulungen]   [Firmenprofil]   [Partner]   [Kunden]   [Information]   [Download]   [News]

LOGO Stor IT Back

ESXi Sicherung von virtuellen Maschinen V1.5 (c) Stor IT Back 2013

Sicherung von virtuellen Maschinen auf VMware ESXi mit ghettoVCB

Der VMware ESXi Server ist nach der Installation ein in sich geschlossenes System. Die Administration ist nur über den Client möglich, eine Automatisierung ohne einen Center Server (und damit die kostenpflichtige Version) ist nur beschränkt möglich. VMware bietet zwar API Clients und Administrationserweiterungen an, die sind aber bei der kostenfreien ESXi Version sehr beschränkt. Das sind dann je nach Version nur lesende Zugriffe möglich.
Der ESXi nutzt auch ein Linux-Betriebssystem als Unterbau, jedoch ist der Shell-Zugang per Default beim ESXi blockiert und selbst dann ist die Shell relativ abgespeckt vorhanden. Aber die Shell ist ausreichend, um Skripte zu installieren und diese auch zu automatisieren. Selbst eine einfache Steuerung über einen Windows oder Linux Client ist möglich.

Öffnen des SSH Zugangs zum VMware ESXi 4.1 und neuer

Ab 4.1 Update 1 der ESXi Software darf der Shell-Zugang offiziell geöffnet werden. Es bestehen keine Service-Einschränkungen nach diesen Änderungen. Der Shell Zugang (per SSH) wird über den vSphere Client aktiviert.
Hier muss der jeweilige ESXi Server ausgewählt werden. Unter dem Reiter "Konfiguration" und "Sicherheitsprofil" können einzelne Funktionen aktiviert und auch wieder deaktiviert werden. Unter "Diensteigenschaften" sind die einzelnen Remote-Dienste des ESXi zu finden. Für den SSH-Zugang wird der "Remote-Support (SSH)" benötigt. Die direkte Console (durch Drücken von Alt-F1) wird durch "Benutzerschnittstelle der direkten Konsole" geöffnet.
Alle Dienste können direkt beim Starten des Servers aktiviert werden, aber auch nur temporär durch manuelles Starten in diesem Fenster aktiviert werden.

Damit ist der ESXi ab der Version 4.1 Update 1 wesentlich komfortabler für den direkten Shell-Zugang geworden.

Hinweis: Seit der 5.x wird eine Warnmeldung herausgegeben, wenn der SSH Zugang geöffnet wird. Das ist zwar nicht schlimm, aber eine immer vorhandene Warnmeldung kann schnell mal eine wichtige Warnung "verstecken". Aber diese Warnung kann deaktiviert werden. Öffnen Sie im vSphere Client die "Konfiguration" des ESXi und suchen Sie unter "Software" und "Erweiterter Einstellungen" den Punkt "UserVars". Dort ist ganz unten der Punkt "UserVars.SuppressShellWarning" mit dem Wert "0". Um die Meldung zu deaktivieren muss dieser Wert auf "1" geändert werden. Sofort wird die Meldung ausgeschaltet.

Öffnen des SSH Zugangs zum VMware ESXi 4.0 und älter

Hierbei zuerst einige Hinweise: Der SSH Zugang bzw. der Consolen-Zugang ist eigentlich nur für den Support gedacht. Jede Manipulation bzw. Änderungen am System oder der Shell führt zum Verlust des Supports. Die Stor IT Back übernimmt keinerlei Haftung für Schäden, die durch diese Anleitung verursacht wurden. Wir weisen darauf hin, dass selbst kleine Fehler in den Anpassungen zum Ausfall des ESXi Systems führen können.

Wie wird jetzt aber der SSH Zugang ermöglicht?
Als erstes muss auf der ESXi Console (Bildschirm und Tastatur) der erste Zugriff auf das Betriebssystem erfolgen:
1. Drücken von <ALT><F1> auf der Console
2. Eintippen von "unsupported" (ohne Anführungszeichen)
3. Eingeben des root-Passwortes
Jetzt ist eine Shell geöffnet, aber der Zugang über SSH muss erst freigeschaltet werden:
4. vi /etc/inetd.conf
5. Das "#" in der Zeile mit ssh entfernen (mit tcp bzw. tcp6)
6. Den vi mit ":wq" verlassen (wq = write + quit)
7. Wenn der ESXi Server neu gestartet werden kann, dann ist dies die einfachste Lösung.
Wenn nicht, dann weiter mit:
8. ps | grep inetd
9. Die Prozess-ID (erste Zahl im Output) notieren
10. kill -HUP <Prozess-ID>, damit wird der inetd mit neuer Konfiguration neu gestartet.

Jetzt sollte der SSH Zugang zum ESXi Server offen sein. Diese Konfigurationsänderung bleibt auch nach einem Reboot erhalten. Nach einem Update der ESXi Software könnte der Zugang evtl. wieder gesperrt werden, wenn die geänderte inetd.conf bei einem Update neu eingespielt wird. Die Verbindung kann jetzt mit einem SSH Tool getestet werden. Zum Beispiel Putty auf Windows oder open-ssh auf Linux.

Das Backup-Skript ghettoVCB.sh

Dieses Skript wurde von William Lam entwickelt und ist auf den Community-Seiten von VMware veröffentlicht. Das ghettoVCB Skript wurde mehrfach den neuen Versionen von ESX und ESXi angepasst. Sie können dieses Skript unter dem Namen ghettoVCB.sh (bzw. ghettoVCB.zip) bei communities.vmware.com oder hier downloaden. Die Stor IT Back übernimmt keinerlei Haftung für die Funktion dieses Skriptes.
Das Skript orientiert sich an dem VCB-Produkt von VMware (daher auch der Name, heute sind das die StorageAPI). Es bietet die Möglichkeit, virtuelle Maschinen auf einem ESX(i) Server auf NFS oder SAN-Filesysteme (VMFS) zu kopieren. Das Skript kann hierzu die VM herunterfahren, einen SnapShot anlegen und diesen dann auf ein Ziel-Filesystem clonen. Dieser Clone enthält alle Informationen, um daraus wieder eine VM zu erstellen. Werden die VMs zum Beispiel auf einen NFS-Server gesichert, so können die VMs im K-Fall direkt wieder aus dem NFS Filesystem heraus gestartet werden. Eine sehr schnelle Recovery ist damit auch bei großen Datenmengen möglich.
Das Skript nutzt die internen Funktionen des ESXi. Die SnapShots und Clone werden direkt über die Programme des ESXi realisiert. Dadurch wird sichergestellt, dass die Kopien auch wirklich nutzbar sind.

In der zip-Datei ist das ghettoVCB.sh Skript vorhanden, sowie eine globale ghettoVCB.conf Konfigurationsdatei und ein Template für die Sicherung einer VM. Zusätzlich ist auch noch ein Skript für den Restore einer VM enthalten, dieses Skript wird hier aber nicht behandelt.
Das aktuelle ghettoVCP.sh Skript ist aufgebaut wie die alten Versionen auch, mit einem Konfigurationsteil am Anfang des Skriptes. Neben dieser Konfiguration können die Einstellungen aber auch über die globale ghettoVCB.conf vorgenommen werden. Sollen unterschiedliche Einstellungen pro VM genutzt werden (zum Beispiel die Anzahl der Versionen), so kann dies in einer VM-spezifischen Datei erledigt werden.

WICHTIG: Das Skript sichert nur virtuelle Maschinen, wenn vor dem Start des Skriptes keine SnapShots von dieser VM vorhanden waren!

Kopieren des Skriptes und der Dateien auf den ESXi Server

Der ESXi Server hat eine komfortable Möglichkeit, um Daten in das Filesystem zu bekommen. Dies geht am einfachsten über den VSphere-Client. ESXi Datenspeicher Browser Unter dem ESXi Server den Reiter "Konfiguration" und dann links die Auswahl "Speicher". Jetzt mit der rechten Maustaste auf den Datenspeicher klicken (default = datastore1) und "Datenspeicher durchsuchen" auswählen. Es öffnet sich ein Fenster, mit dem das Skript und die Konfigurationsdateien (ghettoVCB.conf und VMxxx.conf) auf den ESXi Server hochgeladen werden können. Wichtig ist, dass keine Steuerzeichen im Skript oder den Dateien vorhanden sind. Dann wäre es unter dem ESXi Betriebssystem nicht ausführbar. Dies lässt sich einfach kontrollieren, in dem das Skript einmal mit vi aufgerufen wird und der Editor dann mit ":q!" verlassen wird. Sind am Zeilenende keine "^M" Zeichen enthalten ist alles OK.

Tipp: Sind die "^M" Steuerzeichen in der Datei vorhanden, so lassen sich diese auch unter ESXi wieder entfernen:
1. sed 's/'"$(printf '\015')"'$//g' ghettoVCB.sh > zzz.temp
2. mv zzz.temp ghettoVCB.sh

Jetzt muss das Skript aber auch noch unter ESXi ausführbar gemacht werden. Dazu wird wieder der SSH Zugang benötigt. Wechseln Sie dann in das Verzeichnis /vmfs/volumes/<Datenspeicher> und dort müsst sich dann das Skript befinden. Das Skript kann mit dem Befehl "chmod 750 ghettoVCB.sh" ausführbar gemacht werden. Jetzt könnte das Skript gestartet werden, jedoch fehlt noch die Konfiguration. Also bitte nicht jetzt schon starten!
Tipp: Da neben dem Skript und der globalen Konfigurationsdatei unter Umständen auch noch pro zu sichernder VM eine Datei vorhanden ist, bietet es sich an, alle Daten in ein extra Unterverzeichnis zu legen. Das Unterverzeichnis lässt sich auch mit der GUI anlegen.

Hinweis für ESXi 5.1: Das Skript ist zurzeit noch nicht für die ESXi 5.1 Version angepasst worden. Daher wird der Aufruf des Skriptes mit dem Hinweis abgebrochen, dass eine nicht unterstützte ESXi Version eingesetzt wird. Diese Änderung muss direkt im Skript durchgeführt werden. Um den vi im ESXi zu vermeiden, kann die Änderung auch vor dem Kopieren auf einem Windows Client durchgeführt werden. Die Änderung bzw. Ergänzung im Skript ist fett markiert:

ESX_VERSION=$(vmware -v | awk '{print $3}')
if [[ "${ESX_VERSION}" == "5.0.0" ]] || [[ "${ESX_VERSION}" == "5.1.0" ]]; then
VER=5
elif [[ "${ESX_VERSION}" == "4.0.0" ]] || [[ "${ESX_VERSION}" == "4.1.0" ]]; then
VER=4
else
ESX_VERSION=$(vmware -v | awk '{print $4}')
if [[ "${ESX_VERSION}" == "3.5.0" ]] || [[ "${ESX_VERSION}" == "3i" ]]; then
VER=3
else
echo "You're not running ESX(i) 3.5, 4.x, 5.x!"
exit 1
fi
fi

Konfiguration des ghettoVCB.sh

Die Grundkonfiguration des ghettoVCB.sh wird im Skript bzw. in der ghettoVCB.conf durchgeführt. Dazu muss das Skript entweder mit dem internen Editor "vi" geöffnet werden, oder vor dem Hochladen auf den ESXi Server unter Windows editiert werden. Wichtig ist hierbei, dass keine Steuerzeichen in das Skript eingefügt werden. Die Einstellungen sind alle im ersten Teil des Skriptes vorzunehmen oder in einer externen Konfigurationsdatei, die dann beim Programmaufruf mit übergeben werden muss:

######################################
# directory that all VM backups should go (e.g. /vmfs/volumes/SAN_LUN1/mybackupdir)
VM_BACKUP_VOLUME=/vmfs/volumes/backup_nfs/esxi_1
# 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=3
# 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
# Disk adapter type: buslogic, lsilogic or ide
ADAPTER_FORMAT=buslogic
# Include VMs memory when taking snapshot
VM_SNAPSHOT_MEMORY=0
# Quiesce VM when taking snapshot (requires VMware Tools to be installed)
VM_SNAPSHOT_QUIESCE=0
# 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.30.0.195
# Path of exported folder residing on NFS Server (e.g. /some/mount/point )
NFS_MOUNT=/nfsshare
# Non-persistent NFS datastore display name of choice
NFS_LOCAL_NAME=backup_nfs
# Name of backup directory for VMs residing on the NFS volume
NFS_VM_BACKUP_DIR=esxi_1
# Email debug 1=yes, 0=no
EMAIL_DEBUG=0
# Email log 1=yes, 0=no
EMAIL_LOG=1
# Email SMTP server
EMAIL_SERVER=smpt.abctestfirma.de
# Email SMTP server port
EMAIL_SERVER_PORT=25
# Email FROM
EMAIL_FROM=root@ghettoVCB
# Email RCPT
EMAIL_TO=admin@abctestfirma.de
###########################################################

Tipp wenn die E-Mail nicht ankommt: Ab dem ESXi 5 ist die Firewall auf dem ESXi sehr restriktiv. Ein Versenden von E-Mails aus dem ESXi ist nicht ohne weiteres möglich. Die Firewall kann zwar auch per SSH geöffnet werden, aber einfacher ist es für SMTP einfach einen freien Port zu nutzen. Im Skript definiert man den EMAIL_SERVER_PORT=53 (dieser ist in der Firewall ausgehend geöffnet), jetzt muss nur noch der E-Mail Server auch auf den Port 53 hören. Ist der E-Mail Server nicht auch noch DNS Server, dann ist das mit den meisten MTA-Agenten möglich. Es wird neben dem Port 25 einfach auf einen zweiten Port gelauscht. Bei Postfix ist dies zum Beispiel nur eine Zeile in der master.cf.

Die Konfiguration des Zielverzeichnisses wird entweder im oberen Bereich über einen festen Datastore oder im unteren Bereich über einen temporären NFS Share durchgeführt. In diesem Beispiel wird in beiden Fällen das Verzeichnis /vmfs/volumes/backup_nfs/esxi_1 genutzt. Bei dem "non persistent" NFS Share wird das Verzeichnis nur für den Zeitraum der Sicherung gemountet. Der Name "backup_nfs" ist der Name des Datenspeichers. Er ist auch im VSphere Client sichtbar.
Da dieses Skript automatisiert ausgeführt werden kann, können auch die Anzahl der vorgehaltenen Sicherungen und das Unterverzeichnis für die einzelnen Versionen vorgegeben werden. Bei einem "Rotation_Count" von 3 werden immer 3 Sicherungen vorgehalten, die vierte Sicherung löscht automatisch die älteste Kopie.
Soll die virtuelle Maschine vor der Sicherung heruntergefahren werden, so muss der Parameter "VM_Power_Down" gesetzt werden. Jetzt wird vor der Sicherung die VM heruntergefahren und hinterher wieder gestartet. Das ist wichtig, da das Betriebssystem (und die möglichen Anwendungsdaten) nur konsistent sind, wenn die Maschine komplett heruntergefahren wurde. Mit diesem Skript ist auch ein konsistenter Snap Shot über die "Quiesce VM" Funktion möglich. Damit kann die VM weiter laufen, wird nur für die Zeit des Snap Shots eingefroren.
Welche virtuelle Maschine jetzt gesichert werden soll, wird in einer zusätzlichen Parameter-Datei festgelegt. In dieser Datei stehen die zu sichernden VMs mit Namen, jeweils ein Eintrag pro Zeile. So kann sogar von außen über diese Datei vorgegeben werden, welche VM gesichert werden soll. So kann dann zum Beispiel das Skript jede Nacht gestartet werden und wenn eine VM gesichert werden soll, dann wird einfach die Parameterdatei mit dem Namen versehen an die richtige Stelle kopiert und nach erfolgreicher Sicherung wieder gelöscht.

Eine weitere Verbesserung des Skriptes ermöglicht auch die Vorgabe der Konfiguration in einer Datei (statt im Skript direkt). Damit können komfortabel mehrere Konfigurationen vorgehalten werden. Sollen z.B. Monatssicherung auf andere Medien gespeichert werden, so kann einfach eine andere Konfigurationsdatei verwendet werden. Weiterhin kann über diese Datei auch gesteuert werden, dass nur einzelne vmdk's einer virtuellen Maschine gesichert werden soll. Der Parameter VMDK_FILES_TO_BACKUP="system.vmdk,admin.vmdk" bewirkt, dass nur die beiden virtuellen Platten system.vmdk und admin.vmdk gesichert werden. Aber wofür ist das jetzt gut? Wenn zum Beispiel nur das System eines "großen" Servers gesichert werden soll, dann geht das wesentlich schneller, wenn große Datenpartitionen nicht mit gesichert werden müssen. Oder ein Fileserver, der unter anderem große Datenmengen auf Archivlaufwerken enthält, die sich nicht mehr ändern können. Dann werden die Archive nur einmal gesichert und danach nicht wieder. Auch das spart Zeit.

Eine wichtige Ergänzung des Skriptes ist die E-Mail Funktion. Dies ist sehr wichtig, da man jetzt einfach und ohne weitere Skripte über den Erfolg der Sicherung informiert wird. Man kann sich einfach nach der Sicherung das Log zuschicken lassen. Ist am Morgen kein Log im Postfach, dann ist die Sicherung nicht gelaufen oder sie läuft noch. Ist das Log ohne Fehler im Postfach war alles erfolgreich.

Eine Sicherung einer virtuellen Maschine durchführen

Um eine Sicherung durchzuführen gibt es zwei Möglichkeiten: Das Starten von Hand und die Automatisierung per cron. Der Start von Hand ist recht einfach. Es wird wieder die Anmeldung per SSH benötigt, dann in das richtige Verzeichnis wechseln (cd /vmfs/volumes/datastore1/ghettoVCB), die Parameterdatei anlegen bzw. modifizieren (vi backup.txt) und dann das Skript starten (./ghettoVCB.sh -f backup.txt). Die Ausgaben des Skriptes werden direkt angezeigt:

[root@esxi]# ./ghettoVCB.sh -f backup.txt
Powering off initiated for vm1, backup will not begin until VM is off...
VM is still on - Iteration: 1 - waiting 3secs
VM is still on - Iteration: 2 - waiting 3secs
VM is off
################## Starting backup for vm1... #####################
Destination disk format: VMFS thick
Cloning disk '/vmfs/volumes/datastore1/vm1/vm1_1.vmdk'...
Clone: 100% done.
Destination disk format: VMFS thick
Cloning disk '/vmfs/volumes/datastore1/vm1/vm1.vmdk'...
Clone: 100% done.
Powering back on vm1
#################### Completed backup for vm1! ####################

Start time: Tue Jan 6 16:09:35 PST 2009
End time: Tue Jan 6 16:12:12 PST 2009
Duration : 2.62 Minutes

Completed backing up specified Virtual Machines!

Sind in diesem Beispiel verschiedene virtuelle Maschinen zu sichern, die aber mit unterschiedlichen Optionen bearbeitet werden sollen, dann kann auch pro zu sichernder virtuellen Maschine eine Konfigurationsdatei mit Namen der virtuellen Maschine angelegt werden. Jetzt kann zum Beispiel die eine virtuelle Maschine offline gesichert werden, eine andere aber Online. Oder die Anzahl der Versionen kann unterschiedlich gesetzt werden. Der Aufruf des Skriptes ändert sich dann etwas:

<Verzeichnis>/ghettoVCB.sh -f <Verzeichnis>/backup.txt -c <Verzeichnis>

Wichtig ist jetzt, dass die globalen Einstellungen im Skript vorhanden sind, die Anpassungen dann jeweils in den einzelnen Konfigurationsdateien (Datei-Name gleich VM-Name, ohne Endung conf).

Soll das Backup jetzt automatisiert laufen, so muss es von dem Daemon "cron" gestartet werden. Cron wird von einer einfachen Syntax gesteuert. Änderungen an der Konfiguration werden in der Datei /var/spool/cron/crontabs/root durchgeführt. Das Format in dieser Datei ist:

Minute Stunde Tag Monat Tag_der_Woche Kommando

Wenn wir das Skript jetzt also jeden Werktag um Mitternacht starten wollen, dann würde der Syntax so laufen:

0 0 * * 1-5 /vmfs/volumes/datastore1/ghettoVCB/ghettoVCB.sh -f /vmfs/volumes/datastore1/ghettoVCB/backup.txt

oder

0 0 * * 1-5 /vmfs/volumes/datastore1/ghettoVCB/ghettoVCB.sh -f /vmfs/volumes/datastore1/ghettoVCB/backup.txt -c /vmfs/volumes/datastore1/ghettoVCB

Das Skript muss in diesem Fall mit dem vollen Pfad aufgerufen werden, da der "cron" die Programme aus dem Root-Verzeichnis aus starten will. Also müssen auch die Parameterdatei und das Log mit vollem Pfad angegeben werden. Am nächsten Morgen muss also nur noch die E-Mail geprüft werden und das Backup ist abgeschlossen. Die Datei mit den cron Definitionen ist schreibgeschützt. Beim vi lässt sich dieser Schutz mit ":wq!" umgehen.

Wichtig ist jedoch noch, dass der Cron nach einer Änderung neu gestartet wird. Das geht am einfachsten mit "kill $(cat /var/run/crond.pid)" und danach mit einem "busybox crond" neu starten. Danach sollte dann das automatisierte Backup laufen. Achtung: Jedoch erst mal nur bis zum nächsten Reboot.

Sicherung der Änderungen für den nächsten Reboot

Die Einträge in der cron Datei sind nicht boot-fest. Da muss zu einem Trick gegriffen werden. Die Änderungen müssen bei jedem Reboot des ESXi Servers neu durchgeführt werden. Hierzu bietet sich die Datei /etc/rc.local (für die ESXi 4er Versionen) oder /etc/rc.local.d/local.sh (für die ESXi 5er Versionen) an. Diese Datei wird bei jedem Boot gestartet und kann durch zusätzliche Einträge erweitert werden. Also an das Ende der rc.local die von Hand gemachten Einträge einfügen:

Für die ESXi 4er Versionen:

/bin/echo "0 0 * * 1-5 /vmfs/volumes/datastore1/ghettoVCB/ghettoVCB.sh -f /vmfs/volumes/datastore1/ghettoVCB/backup.txt >> /vmfs/volumes/datastore1/ghettoVCB.log" >> /var/spool/cron/crontabs/root
/bin/kill $(cat /var/run/crond.pid)
/bin/busybox crond

Für die ESXi 5er Versionen:

/bin/echo "0 0 * * 1-5 /vmfs/volumes/datastore1/ghettoVCB/ghettoVCB.sh -f /vmfs/volumes/datastore1/ghettoVCB/backup.txt >> /vmfs/volumes/datastore1/ghettoVCB.log" >> /var/spool/cron/crontabs/root
/bin/kill $(cat /var/run/crond.pid)
/usr/lib/vmware/busybox/bin/busybox crond

Diese Konfiguration muss jetzt noch als Boot-Vorlage für den nächsten Start gesichert werden. Dies lässt sich durch das Skript "/sbin/auto-backup.sh" realisieren. Dieses Skript wird ansonsten jede Stunde vom "cron" gestartet, aber wer will schon eine Stunde warten.

Jetzt sind alle Einträge vorhanden. Zum Test sollte der ESXi Server einmal neu gestartet werden und die Sicherungen sollten einmal komplett durchlaufen und besonders getestet werden. Hier bietet es sich an, von einem zweiten System aus die Clone einmal zu starten. Da muss dann besonders drauf geachtet werden, dass es nicht zu Konflikten mit den produktiven Maschinen kommt. Stichwort: Netzwerke und doppelte IP-Adressen.

Restore einer virtuellen Maschine

Durch diese Sicherungsmethode, die ja eigentlich eine Kopie der virtuellen Maschine anlegt, ist die Recovery oder der Restore sehr einfach. Als erstes wird der NFS-Share an einen ESXi Server gemountet. Danach kann die virtuelle Maschine in die Bestandsliste des ESX übernommen werden (im Datenspeicherbrowser die rechte Maustaste auf die *.vmx Datei und dann "Hinzufügen zur Bestandsliste"). Jetzt kann die VM direkt gestartet werden. Eine sehr schnelle Recovery.
Aber Achtung: Wenn Sie die VM direkt starten ist damit die Sicherung nicht mehr vorhanden. Die Änderungen gehen direkt auf die kopierte VM. Bei Problemen mit dem System oder mit Daten sollte vorher eine Kopie der Daten angelegt werden.

Selbst einzelne Dateien können aus der virtuellen Maschine restored werden. Es ist zwar etwas umständlich, geht aber trotzdem recht schnell. Die benötigte VM wird auf einem anderen ESXi (oder dem gleichen) der Bestandsliste hinzugefügt, aber vor dem Starten müssen die Einstellungen verändert werden. Alle Informationen, die diese VM ins LAN gibt, müssen verhindert werden. Sonst würde z.B. der Exchange aktiv werden und E-Mails verschicken. Auch haben wir dann doppelte IP-Adressen im Netz. Verbannen wir die kopierte VM in ein eigenes isoliertes Netz, dann können wir sie starten. Über dieses isolierte Netz die benötigten Daten kopieren und dann die VM wieder stoppen. Wenn man dieses einmal vorbereitet hat, zum Beispiel mit einem zusätzlichen virtuellen Client im isolierten Netz, dann ist eine schnelle Datei-Recovery möglich.

Sicherheitshinweise


Für alle die sich mit Linux nicht so gut auskennen, sollte vor Änderungen am System immer ein Blick in die Dokumentation zu Linux stehen. Wichtig sind hierbei die Befehle vi (der Editor), cron (der Scheduler), inetd (Superdeamon) und die Standard-Befehle wie ls, ps, kill und cd.
Und noch mal der Hinweis: Die Änderungen am ESXi System können zum Nichtstarten bzw. zum Absturz des ESXi Betriebssystem führen. Im schlimmsten Fall sind sämtliche Daten verloren. Machen Sie deswegen vorher eine Sicherung der gesamten Daten.

Zum Thema Server-Virtualisierung bieten wir verschiedene Workshops an. Einmal einen regelmäßig statt findenden Einsteiger-Kurs mit Grundlagen und Lösungsvorschlägen und einen optional Workshop mit einem großen Praxisteil, die Virtualisierung zum Anfassen.

Für Virtualisierungsprojekte bieten wir die passenden Storage-Lösungen an, setzen Sie sich mit uns in Verbindung. Natürlich können Sie auch komplette Lösungen von uns bekommen. Egal zu welcher Virtualisierungssoftware, wir finden ein für Sie passendes Storagesystem.

Angebote der Stor IT Back zum Thema Server-Virtualisierung

Angebot Veeam Backup and Replication for VMware
Veeam Backup und Replication
für VMware und Hyper-V inkl. 1 Jahr Support
Backup and Replikation für virtuelle Umgebungen
für Exchange, MS-SQL, Oracle, AD, ...
ab 700,00 Euro
zzgl. MwSt.
Angebot VMware ESXi Server Virtualisierung iSCSI

VMware ESXi Essentials Paket iSCSI
2 Fujitsu RX2530 Server für VMware ESXi
und Supermicro Open-E iSCSI Speicherplatz
ab 12.653,00 Euro
zzgl. MwSt.
Angebot VMware ESXi Server Virtualisierung iSCSI

VMware ESX Fibre Channel Paket (Essentials Plus)
2 x Fujitsu RX2520 M1 Server für VMware ESXi
und EMC VNXe1600 FC mit SAS Platten
ab 23.855,00 Euro
zzgl. MwSt.
 
 
Zurück zur Übersicht
Übersicht
nach oben
nach oben
Übersicht der Angebote
Angebote
Kontakt zur Stor IT Back
Kontakt
Suche auf der Webseite
Suche