Fragen zum Recovery eines ESXi Servers nach Defekt

Bib

Enthusiast
Thread Starter
Mitglied seit
20.12.2006
Beiträge
714
Hallo,
vorerst möchte ich anmerken, dass bei mein Server keine Probleme macht und diese Fragen nur für den Fall der Fälle gedacht sind, haben also keine aktuelle Bewandtnis. Ich würde aber gerne mehr darüber erfahren und mein Sicherheitskonzept dann danach anpassen.

Was ich habe:

ESXi Lizenz
Veeam Backup&Recovery Lizenz

Folgender Aufbau:

Dell T20 mit ESXi auf USB-Stick
1x SSD 256 GB am internen Controller, darauf liegen folgende VMs
  • FreeNAS (extra SATA-Controller durchgereicht, daran 2x HDD im ZFS Raid1)
  • Win 10
  • debian für diverse Serverdienste
  • ubuntu für Plex Squeezebox-Server usw


Die Config von FreeNAS ist aktuell gesichert, auf dem Server selbst, auf meinem Notebook und auf einer externen HDD.

Auf der Win 10-VM läuft Veeam als Server mit einem Backup-Repository, welches auf dem FreeNAS-Speicher liegt. Ich sichere damit alle meine VMs (bis auf FreeNAS, das geht damit nicht) wöchentlich. Zusätzlich sichere ich die Win 10 VM noch mittels dem kostenlosen Veeam Agent for Windows und ich habe dafür auch ein Bootmedium erstellt.

Hier ist dann gleich meine Fragen dazu:

1.)
Reicht die VM-Sicherung über Veeam-Server oder bin ich bei meiner Config mit dem Veeam Agent for Windows für meien Win10-VM besser bedient? Ich meine, wenn ich Win10 zurücksichern muss, dann habe ich ja noch keinen laufenden Veeam-Server und muss die Win10-VM erstmal über das Bootmedium wiederherstellen, oder nicht?

2.)
Im Fehlerfall, wenn ich von komplett vorne anfangen muss wie gehe ich dann vor?
Etwa so?

a) ESXi-USB-Stick neu erstellen - ggf. Config zurückspielen oder zumindest eine einzige VM für die FreeNAS-Neuinstallation aufsetzen

b) FreeNAs in der neuen VM installieren und Config zurücksichern
  • Muss ich in FreeNAS dann noch großartig was machen oder werden meine ZFS-Pools sofort erkannt?
c) weitere VM aufsetzen und mit dem Veeam-Boot-Image starten und die Win10-VM zurück sichern mit dem Backup vom lokalen Veeam Agent for Windows
  • die VM-Sicherung vom Veeam-Server nutzt mir hier erstmal noch nichts, oder?
d) mittels Veeam Server die restlichen Linux-VMs zurücksichern
  • Muß ich hier in ESXi erstmal die grundlegenden Einstellungen machen, also je VM diese erst anlegen oder wird das mit Veeam alles komplett zurück gesichert und ich muss in ESXi nichts extra machen?

3.)
Wenn ich zukünftig meine Konfiguration so umbauen möchte, dass ich auch die SSD an FreeNAs durchreiche, per NFS zurück an ESXi gebe und die weiteren VMs dann darauf installiert werden sollen, ändert dann an der Vorgehensweise großartig was oder ist das nehezu die selbe Arbeit, die ich im Fehlerfall machen muss?
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Das ist eigentlich ein ideales Szenario für ein (virtuelles) Homelab :-)

ZFS Pools kannst du du in eine neue FreeNAS Installation importieren, config kannst du auch wegsichern.
VMs am besten mit dem kostenlosen Veeam sichern oder eine ZFS all-in-one Lösung mit NFS Freigabe verwenden.

Je nach dem was defekt ist musst du natürlich ESXi neu installieren.

Veeam legt beim Restore die VMs wieder neu an, du brauchst diese nicht manuell neu aufsetzen.


Hol dir doch VMWare Workstation/Player und richte dir doch mal eine komplette virtuelle Umgebung ein, da kannst alles ausprobieren und bist für den Ernstfall vorbereitet.

Die Windows 10 VM mit dem Agent zu sichern ist am Ziel vorbei, das kannst du auch direkt als VM sichern.
 
Zuletzt bearbeitet:
Meinst du mit "kostemlosem Veeam sichern" jetzt nur die Win10-VM, damit ich dann meinen Veeam-Server wieder starten und von da aus alle anderen VMs zurücksichern kann oder auch die Linux-VMs mit dem kostenlosen Veeam-Agent for Linux und zugehörigem erstellten Bootmedium? Die Lösung mit dem Server ist doch viel komfortabler, oder nicht?

Wenn ich die Win10-VM zurücksichere, dann muss ich die VM aber in ESXi schon erstmal manuell anlegen, ich muss dann ja das Bootmedium (ISO) als Datenträger einbinden usw... Der komplette Restore inklusiv aller VM-Settings (durchgereichte Geräte usw) funktioniert doch nur, wenn ich das über den Veeam-Server zurück sichere, oder?

Die mit Veeam Agent for Windows erstellten Sicherungen kann ich doch auch ganz normal mit dem Veeam-Server wieder zurück spielen? Die sind kompatibel zu den VM-Sicherungen von Veeam-Server? Oder fehlt da dann der Teil mit den Einstellungen innerhalb ESXi?

Für meine Win10-VM reicht es dann eigentlich aus, wenn ich diese ausschließlich mit Veeam free sichere und nur die Linux-VMs mit dem Veeam-Server?

____________________________

Und der andere Fall, falls ich die VMs auf eine FreeNAS-NFS Freigabe installieren sollte:
Dann mache ich zuerst mal mein FreeNAS wieder lauffähig und habe dann alle Daten auf den HDDs und SSDs - aber in einem frischen ESXi ist dann ja nur die FreeNAS-VM drin. Kann ich die VMs dann mit allen Settings (durchgereichten Geräten usw) von meiner SSD einlesen oder müsste ich jede VM zuerst wieder manuell anlegen?

Dann wäre wohl eine Sicherheitskopie des ESXi-USB-Stick oder zumindest eine Sicherung der ESXi-Config noch ganz gut, oder?

Hab die Settings von ESXi jetzt mal mit
/bin/firmwareConfig.sh --backup /tmp/
erstellt und weggesichert.
 
Zuletzt bearbeitet:
Ich glaube du bringst da ein paar Dinge durcheinander oder ich gehe von anderen Dingen aus.

Du kannst mit Veeam Backup & Replication Free komplette VMs absichern, egal ob Windows oder Linux. Wo die Sicherung oder Wiederherstellung läuft ist total egal, wichtig nur das du nachher einen funktionierenden ESXi Host hast auf dem du mit Veeam zurücksichern kannst.

Eine andere Möglichkeit, da du sowieso FreeNAS/ZFS nutzt, um komplett die Problematik mit Veeam zu umgehen, wäre die interne Bereitstellung des FreeNAS Storages über NFS. FreeNAS 9.10 on VMware ESXi 6.0 Guide | b3n.org

Mittels ZFS Snapshots hättest du dann einen Datenstand den du per Replication auch woanders hin wegsichern könntest.
 
Ich beschreibe mal kurz, wie ich es mache :d

Ich habe jetzt zwei Havarien hinter mir und komme mit meinem Ansatz absolut problemlos und schnell wieder in Produktion. Mir scheint das Ganze mit Veem doch arg "komplex". Man braucht ja immer auch eine Windows-Maschine, die läuft. Mich hatte das bei meiner Suche nach einer Backup-Lösung abgeschreckt und ich habe lange gesucht. Fürs Backup bin ich schliesslich bei xsibackup gelandet. Das hat den Vorteil, wirklich lean und native auf ESXI (!) zu laufen, also nicht in einer VM.

Mein grundsätzliches Setup:

1) Boot-SATA-Dom, darauf ESXI und ersten Datastore, auf welchem die NAS-VM liegt. Diese Boot-HD ist wiederherzustellen, der Rest ergibt sich von selbst.
2) Einmal ein ZFS-nfs-datastore für alle produktiven non-NAS-VMs
3) Ein weiteres ZFS-nfs-datastore für VM-Backups
4) Eine weitere SSD als zweiten, lokalen Datastore für VM-Backups, ISOs, ESXI-Config-Backup, xsibackup-Programm, etc. Damit habe ich direkten Zugriff auf die wichtigsten Daten, auch wenn die NAS-VM mal nicht zur Verfügung steht, etwa zum Quick-Recovery zerschossener VMs oder zur Havariebeseitigung :d)

Meine Backups mache ich mit xsibackup, per cron-job, was dann auch immer die aktuelle ESXI-config weg speichert. Meine Backup-Strategie:

a) täglich: alle non-NAS-VMs auf den zweiten, lokalen Datastore
b) wöchentlich: alle non-NAS-VMs auf den ZFS-nfs-Datastore für VM-Backups
c) unregelmäßig: Backup der gesamten NAS auf einen Offline-Datenträger
d) Immer dann, wenn Updates der NAS-VM einen Reboot derselben erfordern oder, wenn ich größere Anpassungen am Setup der NAS-VM gemacht habe, fahre ich die VM herunter und sichere diese ebenfalls auf die beiden VM-Backup-Datastores, also 1x lokal und 1x ZFS-nfs (Ergänzung: ZFS-nfs geht natürlich nur dann, wenn die NAS-VM wieder läuft, Kopie des Backups von lokal auf ZFS-nfs). Dies geht ja leider nur im ausgeschalteten Zustand, da der Festplattencontroller an die VM durchgereicht wird.

Der Vorteil ist nun, dass ich im Havariefalle "nur" ESXI neu installiere und alles Weitere auf der CLI/Shell von ESXI mache. So bin ich in etwa 30 Minuten wieder produktiv:

1) ESXI neu auf ersten, ggf. neuen, lokalen Datastore installieren
2) Die Config vom zweiten, lokalen Datastore wiederherstellen. Dieser wurde bei mir im übrigen immer automatisch wieder eingehangen.
3) Die gesicherte NAS-VM vom zweiten auf den ersten, lokalen Datastore zurück kopieren (keine Neuinstallation, kein Import von Einstellungen, einfach "cp -av vm ...")
4) Nach einem Reboot, mit der wiederhergestellten ESXI-Config, läuft alles, wie bisher. Das System kennt seine Einstellungen, findet die NAS-VM und auf der NAS-VM die dort gespeicherten VMs. Alles bootet in der zuvor festgelegten Bootreihenfolge.

Wie gesagt. Veem ist sicherlich komfortabel. Aber erfordert immer auch noch ein bissl was dazu. Und wenn ESXI nicht läuft, fangen die Probleme schon da an. Mit obigem Ansatz umgehe ich das Ganze und kann binnen Minuten alles wieder aufsetzen.
 
Zuletzt bearbeitet:
@Opticum:
Ich kann die mit Veeam B&R free erstellten VeeamZIP-Sicherungen aber doch nicht direkt in ESXi zurückspielen. Ich benötige dafür doch erst mal ein lauffähiges Win10 mit installiertem Veeam, oder sehe ich das falsch?

Ich müsste somit zumindest die Win10-VM mit Veeam Agent for Windows und damit erstelltem Bootmedium sichern. Dann kann ich in ESXi die Win10-VM zurücksichern und von da ab gehts dann mit Veeam B&R free (oder mit der mir zur Verfügung stehenden Vollversion) weiter.

________

@you:
d) Immer dann, wenn Updates der NAS-VM einen Reboot derselben erfordern oder, wenn ich größere Anpassungen am Setup der NAS-VM gemacht habe, fahre ich die VM herunter und sichere diese ebenfalls auf die beiden VM-Backup-Datastores, also 1x lokal und 1x ZFS-nfs. Dies geht ja leider nur im ausgeschalteten Zustand, da der Festplattencontroller an die VM durchgereicht wird.

Du meinst, letzteres geht nur in eingeschaltetem Zsutand, weil FreeNAS ja laufen muss, um den NFS-Datastore online zu haben? Also erstmal Sicherung lokal, dann FreeNAS starten und die lokale Sicherung auf den ZFS-NFS-Datastore kopieren?


Deine Variante hört sich auch nicht schlecht an. Kann xsibackup eine laufende VM sichern (wie Veeam) oder muss diese dazu erst beendet werden?

So langsam gehen mir dann die SATA-Ports aus. Mein durchgereichter Controller hat nur 4 Ports... 2x HDD für ZFS Raid1, 2x SSD für VM-Raid1 und dann hab ich noch eine einzelne HDD, welche über FreeNAS Speicherplatz für Aufnahmen von meinen Sat-Receivern zur Verfügung stellt. Entweder ich reiche diese dann per RDM an FreeNAS durch oder ich reiche den ganzen internen Controller auch durch, wobei ich dann aber nur noch mit USB-Sticks für die ESXi und FreeNAS-Installation arbeiten kann...
 
Zuletzt bearbeitet:
Es können laufende VM gesichert werden - wenn ich mich richtig erinnere wird dazu ein Snapshot erstellt.Du siehst ja den kompletten ablauf in der Shell, wenn du sie offen lässt und es erstmal händisch machst.
VMWare Backup and replication solution

Ich würde dir empfehlen - wie Opticum auch schrieb, einfach mal die VMWare Workstation Testversion laden, ESXi darin installieren und das ganze mit kleinen VMS durchspielen.Dein PC muss das natürlich auch schaffen ^^

Habe ich so auch gemacht um XSIBackup/ESXi zu testen etc.

Nutze zwar keinen ESXi mehr, aber schlecht war die Lösung nicht.
 
Zuletzt bearbeitet:
@you:


Du meinst, letzteres geht nur in eingeschaltetem Zsutand, weil FreeNAS ja laufen muss, um den NFS-Datastore online zu haben? Also erstmal Sicherung lokal, dann FreeNAS starten und die lokale Sicherung auf den ZFS-NFS-Datastore kopieren?

Genau so ... ich habe es oben mal ergänzt.


Deine Variante hört sich auch nicht schlecht an. Kann xsibackup eine laufende VM sichern (wie Veeam) oder muss diese dazu erst beendet werden?

Yepp ... Ausnahmen sind diejenigen VMs an die irgendwelche Hardware durchgereicht wird. Ansonsten geht es mi Win/OSX/Linux VMs ohne Probleme auch, wenn sie online sind.
 
Zuletzt bearbeitet:
Es handelt sich ja hierbei um mein klassisches AiO Konzept wie ich es schon seit bald 10 Jahren propagiere.

Ich mache das so:
- ESXI: muss man nicht sichern, im Crashfall einfach neu aufsetzen oder ein zweites Bootmedium bereithalten und VMs einfach importieren (ESXi Dateibrowser, Maus-Rechtsklick auf .vmx Datei)

- Auf dem lokalen ESXi datastore liegt die Storage VM. Wenn man die nur für Storage nutzt muss man die nicht sichern (könnte man als Template aus ESXi wegsichern und dann erneut bereitstellen). Bei FreeNAS muss man einfach alle Extras ignorieren. Mein bevorzugtens Solaris Text oder OmniOS sind eh minimalistische Systeme. Da gibts die ganzen Mediaserver und andere Hometools eh nicht, Storage pur, dafür ultra stable.

- Die Storage VM stellt ZFS Storage bereit. ESXi nutzt den via NFS und legt darauf seine VMs ab. Versionierung der VMs geht über ZFS Snaps, Zugriff/Restore auf Vorversionen z.B. per Windows und "vorherige Version" und Backup der (laufenden VMs) über ZFS Snaps (optional mit eingebetteten ESXi Hotsnaps) und ZFS Replikation.

irgenwelche Tools brauchts nicht. ZFS hat alles.
 
Ich versuche mit meinem Setup folgende Szenarien für mein Home-Lab abzudecken:

1) Was ist, wenn die Storage VM nicht mehr online ist, weil bspw. Controller defekt, und Ersatz kommt erst in 5 Tagen?

Dann kann ich in Sekunden zumindest auf die VMs auf dem zweiten, lokalen Datastore zurückgreifen und die wichtigsten Dienste sind asap wieder aktiv. Wichtig für Hausautomation und Hausfrieden :d. --> Das funktioniert im AiO Konzept nicht so problemlos (oder ich übersehe hier was).

2) Was ist, wenn das Boot-Device defekt ist?

Mit meinem Setup ist das Recovery eine Sache von etwa einer halben Stunde (s.o.). Und da zählen die laaangen Bootzeiten für mein System schon dazu. Ich habe halt immer eine funktionsfähige Storage VM in der Kiste.

--> Das funktioniert im AiO wahrscheinlich schneller, da das Replizieren der Storage VM nicht notwendig ist, wenn diese getrennt vom ESXI Bootdevice gehalten wird.

Der "Vorteil" in meiner Ich-kopiere-die-Storage-VM-Variante ist: Ich nehme für die Storage VM die Kopie einer kompletten VM, mit allen Einstellungen, Usern, was-auch-immer. Ich gehe damit dem "Risiko" nicht funktionierender UID Zuordnungen und Problemen beim Import von gesicherten Einstellungen a priori aus dem Weg. Letzteres birgt ja auch immer ein bissl Komplexität und das Risiko, dass der User (also ich) was vermurkst. Mit dem Ansatz, lediglich eine Kopie machen zu müssen, kann ich auch ohne große Übung fehlerfrei recovern :d
 
Zuletzt bearbeitet:
Ich fahre auch ein ESXi AIO mit Solaris:

ESXi selbst auf kleiner SSD.

Meine Storage VM läuft unter Solaris als Software raid1 mit 2 VMDKs auf zwei unterschiedlichen SSDs (eine davon zugleich mit dem ESXi). Fällt eine aus, egal - Storage VM läuft weiter.

Ist zufällig die SSD auch mit ESXi drauf hinüber, ist ESXi im Hinblick auf die StorageVM super schnell wieder aufgesetzt, da die VM nur eine ESXi-Minimalkonfiguration braucht: HBA im Passthrough und 1 vNIC (im Hauptnetz), fertig.

Himmelt sich CPU/Board/RAM, geht das Backup-System aktiv (auch ein ESXi AIO mit einer zweiten Solaris VM, auf das sonst nur repliziert wird), muss halt dann schauen was ich vom Main-System dann zusätzlich zu den zwei SSDs für die Storage VM physisch umziehe.

Himmelt sich der HBA hab ich einen zweiten hier rumliegen.

Himmelt sich der Expander kann ich halt erstmal nur weniger Platten / Pools nutzen.

Festplatten halt nach RAID-Konfig.

Würde behaupten, länger als 30 wäre das wichtigste Storage nicht weg.
 
1) Was ist, wenn die Storage VM nicht mehr online ist, weil bspw. Controller defekt, und Ersatz kommt erst in 5 Tagen?

Ich kann mich an keinen Fall erinnern indem mir ein HBA einfach so ausgefallen ist. Defekte/Instabile Mainboards oder PSU sind da viel wahrscheinlicher.

Ideal ist dann halt ein zweiter AiO für Backup und Failover. Der kann auch älter/ einfacher sein.

2) Was ist, wenn das Boot-Device defekt ist?

Dann ist es egal ob AiO mit VMs auf ZFS oder VMs auf lokal datastore.
Mit ZFS ist halt das Thema Datensicherheit, Performance und Backup/Restore um Welten besser gelöst.
 
Gegen ein defektes Bootdevice hilft halt nur ein Raid1 bzw. 1:1 Backup. Nächstschnellste Variante ist dann ein möglichst schlankes Boot-OS...
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh