Stor IT Back - Ihr Speicherspezialist
ESXi Sicherung von virtuellen Maschinen V1.8 (c) Stor IT Back 2024
Der VMware ESXi Host ist nach der Installation ein in sich
geschlossenes System. Die Administration ist nur über den vCenter Server bzw. ab der 6.5 über die Weboberfläche möglich,
eine Automatisierung ohne einen vCenter Server (und damit die kostenpflichtige
Version) ist nur beschränkt möglich. VMware und Drittanbieter bieten zwar API Clients
und Administrationserweiterungen an, die sind aber bei der kostenfreien ESXi
Version sehr beschränkt. Über die vStorage API for Data Protection, die offizielle Schnittstelle für die Datensicherung von ESXi Systemen, ist ein
Backup eines kostenfreien ESXi nicht 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.
Das Backup-Programm ghettoVCB besitzt keine GUI und wird als Skript direkt auf dem ESXi gestartet.
GhettoVCB bietet viele Features, eine unvollständige Aufstellung finden Sie hier:
- Online Backup von laufenden virtuellen Maschinen
- Unterstützung von mehreren VMDKs pro virtueller Maschine
- Shutdown von VMs vor der Sicherung mit Timeout
- Optimierung des SnapShot Prozesses
- Virtuelle Maschinen mit aktiven SnapShots werden nicht gesichert
- Angabe der Backup-Versionen
- Sicherung auf NFS-Shares, die automatisch gemountet und entfernt werden
- Individuelle Backup-Einstellungen pro VM
- Exclude oder Include einzelne VMDKs pro virtueller Maschine
- SnapShots mit Memory und / oder Quiesce Option
- Sicherung von allen VMs auf einem ESXi ohne Vorgabe der VM Namen
- Logging der Sicherung
- Änderung des Namen einer VM beim Restore
Als Basis muss erst einmal der SSH Zugang zum System geöffnet werden. Ohne diesen Zugang ist die Nutzung
von ghettoVCB nicht möglich. Der SSH Zugang kann direkt über den vSphere Web Client aktiviert werden, dazu muss der Host
ausgewählt werden und dann auf "Manage" und "Settings" geklickt werden. Unter "Security Profile" bei Services dann "Edit". Bei
SSH kann dann "Start and Stop with host" gewählt werden. Damit wird der SSH-Zugang auch nach einem Reboot des ESXi wieder
geöffnet.
Der Zugriff auf die ESXi Shell erfolgt zum Beispiel über Putty von einem Windows System aus, oder per ssh von einem
Linux oder Unix System aus. Der User bei ssh entspricht dem root User aus der Installation mit dem vorgegebenen Passwort.
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.
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 und erweitert. Sie können dieses Skript unter dem
Namen ghettoVCB.sh (bzw. ghettoVCB.zip) bei Github
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 ESXi Server auf NFS oder SAN-Filesysteme (VMFS)
zu kopieren. Das Skript kann hierzu die VM herunterfahren (Offline Backup) oder einen SnapShot anlegen (Backup einer laufenden VM)
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 in dieser Kurzanleitung 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!
Der ESXi Server hat eine komfortable Möglichkeit, um Daten in das Filesystem zu bekommen. Dies geht am einfachsten über den vSphere vCenter Server oder die Weboberfläche des ESXi).
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. Hier kann dann in der Verzeichnisstruktur in neues Verzeichnis angelegt werden. Dort durch "Hochladen" im neuen Fenster, das Skript und die Konfigurationsdateien (ghettoVCB.conf und VMxxx.conf) auf den ESXi Server hochladen. 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.
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:
###################################### LAST_MODIFIED_DATE=2017_12_09 VERSION=1 # 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 # 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 # Comma separated list of VM startup/shutdown ordering VM_SHUTDOWN_ORDER= VM_STARTUP_ORDER= # RSYNC LINK 1=yes, 0 = no RSYNC_LINK=0 ###########################################################
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 SnapShot über die "Quiesce VM" Funktion
möglich. Damit kann die VM weiter laufen, wird nur für die Zeit des
SnapShots 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.
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.
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.
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.
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.
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.
