Stor IT Back - Ihr Speicherspezialist

Stor IT Back

ESXi Sicherung von virtuellen Maschinen V1.8 (c) Stor IT Back 2024


Sicherung von virtuellen Maschinen auf VMware ESXi mit ghettoVCB

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.



 
 

Features von ghettoVCB

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



 
 

Öffnen des SSH Zugangs zum VMware ESXi 6.x, 7.x und 8.x

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.



 
 

Öffnen des SSH Zugangs zum VMware ESXi 4.1 und 5.x

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.



 
 

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 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!



 
 

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 vCenter Server oder die Weboberfläche des ESXi).

ESXi Databrowser

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.



 
 

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:

######################################
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.



 
 

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.



 
 

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.



Workshops und Schulungen zum Thema Server-Virtualisierung

Workshop Cloud Technologien
Workshop Cloud Technologien / Cloud Computing
Cloud Definition / Begriffe
Technischer Aufbau
Vorteile von Cloud Technologien
Was ist auf jeden Fall zu beachten?
Server-Virtualisierung - ein herstellerunabhängiger Überblick
Server-Virtualisierung - ein herstellerunabhängiger Überblick
Grundlagen der Server-Virtualisierung
Betrieb und Überwachung
VMware, Hyper-V, XEN und KVM
Praxisworkshop Server-Virtualisierung
Praxisworkshop Server-Virtualisierung
Aufbau einer Server-Virtualisierung
Hochverfügbarkeit und Sicherheit
Backup-Lösung in der Praxis
Vergleich VMware, Hyper-V, XEN und KVM
 
 

Angebote der Stor IT Back zum Thema Server-Virtualisierung

Angebot Veeam Backup and Replication VUL
Veeam Essentials Backup und Veeam Backup & Replication
für VMware und Hyper-V als VUL
für Exchange, MS-SQL, Oracle, AD, ...
Preis
bitte anfragen
Angebot VMware ESXi Server Virtualisierung iSCSI

VMware vSphere ESXi Einsteiger Paket iSCSI
2 Fujitsu RX2520 Server für VMware ESXi
und Supermicro Open-E Jovian DSS Shared Storage
Preis
bitte anfragen
Proxmox VE auf Lenovo Server
Proxmox VE Virtualisierung
QEMU/KVM und LXC (Linux Containers)

auf Lenovo Server
Single Server bis HA-Umgebung
ab 4.155,00 Euro
zzgl. MwSt.
 
 
Zurück zur Übersicht
ghettovcb datensicherung backup esxi
Übersicht der Angebote
Kontakt zur Stor IT Back
Suche auf der Webseite