Datenrettung
Hilfe in unterschiedlichen Situationen von Datenverlust
work in progress
Vorerst nur nützliche Befehle:
A. Datenrettung aus ESXi-Datenträgern
# ddrescue + vmfs tools holen
apt install gddrescue vmfs-tools
# (möglicherweise ist für neuere VMFS-Platten vmfs6 erforderlich...)
# Funktionen:
# Daten retten auf ein image:
ddrescue -d /dev/sdb /pfad/zum/image/image.img /pfad/zum/log/logdatei.log
# etwas genauer lesen (jeweils 3 Versuche):
ddrescue -d -r3 /dev/sdb /pfad/zum/image/image.img /pfad/zum/log/logdatei.log
# Inhalt des Image einsehen:
vmfs-fuse /pfad/zum/image/image.img /mnt/mountpoint/
apt install gddrescue vmfs-tools
# (möglicherweise ist für neuere VMFS-Platten vmfs6 erforderlich...)
# Funktionen:
# Daten retten auf ein image:
ddrescue -d /dev/sdb /pfad/zum/image/image.img /pfad/zum/log/logdatei.log
# etwas genauer lesen (jeweils 3 Versuche):
ddrescue -d -r3 /dev/sdb /pfad/zum/image/image.img /pfad/zum/log/logdatei.log
# Inhalt des Image einsehen:
vmfs-fuse /pfad/zum/image/image.img /mnt/mountpoint/
B. Rettung eines ESXi-Systems
Auf der Seite https://www.nakivo.com/blog/back-up-and-restore-vmware-esxi-host-configuration-guide/ sind gute Hinweise zum Backup eines defekten Hosts beschrieben. Die wichtigsten Schritte:
=> nachdem in ein Linux-Live-System auf dem Host gebootet wurde:
# list all partitions
ls -al /dev/sd*
# eventuell hilft auch:
fdisk -l | grep /dev/sda # sofern sda das Bootlaufwerk ist
# mount partition (marked as Microsoft basic data oder so...)
mkdir /mnt/sdX
mount /dev/sdX5 /mnt/sdX
#im gemounteten Laufwerk muss sich die Datei state.tgz, allerdings heißt sie eher:
configBundle-xxx-xxx-xxx-xxx.tgz mit IP-Namen
ls -al /dev/sd*
# eventuell hilft auch:
fdisk -l | grep /dev/sda # sofern sda das Bootlaufwerk ist
# mount partition (marked as Microsoft basic data oder so...)
mkdir /mnt/sdX
mount /dev/sdX5 /mnt/sdX
#im gemounteten Laufwerk muss sich die Datei state.tgz, allerdings heißt sie eher:
configBundle-xxx-xxx-xxx-xxx.tgz mit IP-Namen
1. Vorbeugen
Die Konfiguration eines ESXi-Systems sollte ab und zu gespeichert werden (nach jeder wichtigeren Änderung?). Dies geht mit der Konsole so:
2. Dann wiederherstellen
Achtung: gespeicherte config kann nur genutzt werden, wenn das neu aufgesetzte System gleiches build aufweist, die das gesicherte... Teste es mit:
vmware -vl
Wiederherstellen:
3. Spezialfall: Was passiert nach Stromausfall
Es kann sein, dass nach Stromausfall ein ESXi-Host nicht startet, weil "Device Error" beim Booten auftritt und das Booten unterbricht. Ein ähnliches Szenario wird hier beschrieben.
In diesem Fall hat erstaunlicherweise Folgendes geholfen:
Die Konfiguration eines ESXi-Systems sollte ab und zu gespeichert werden (nach jeder wichtigeren Änderung?). Dies geht mit der Konsole so:
# sync configuration changed with persistent storage:
vim-cmd hostsvc/firmware/sync_config
# back-up config data for the ESXi host:
vim-cmd hostsvc/firmware/backup_config
# command will output a URL (http://<host_fqdn_orIP>/downloads/123456/configBundle-xx.xx.xx.xx.tgz) to download the backup file
vim-cmd hostsvc/firmware/sync_config
# back-up config data for the ESXi host:
vim-cmd hostsvc/firmware/backup_config
# command will output a URL (http://<host_fqdn_orIP>/downloads/123456/configBundle-xx.xx.xx.xx.tgz) to download the backup file
2. Dann wiederherstellen
Achtung: gespeicherte config kann nur genutzt werden, wenn das neu aufgesetzte System gleiches build aufweist, die das gesicherte... Teste es mit:
vmware -vl
Wiederherstellen:
# Datei umbenennen:
mv configBundle-HostFQDN.tgz configBundle.tgz
# //maintenance mode// einschalten:
vim-cmd hostsvc/maintenance_mode_enter
# configBundle.tgz kopieren
(z. B. mit) scp ...
# host neu starten (!)
# verschiebe //config bundle// nach top:
mv configBundle.tgz /tmp/configBundle.tgz
# Befehl ausführen:
vim-cmd hostsvc/firmware/restore_config 0
# soll Problem des //UUID mismatch// überschrieben werden, dann besser mit 1:
vim-cmd hostsvc/firmware/restore_config 1
# System startet dann automatisch neu
# Vorsicht: ab ESXi 7.0 U2 //config// kann mit TPM verschlüsselt sein - geht also nur mit gleichem Host; also geht dann //UUID override// nicht, wenn TPM drin war;
mv configBundle-HostFQDN.tgz configBundle.tgz
# //maintenance mode// einschalten:
vim-cmd hostsvc/maintenance_mode_enter
# configBundle.tgz kopieren
(z. B. mit) scp ...
# host neu starten (!)
# verschiebe //config bundle// nach top:
mv configBundle.tgz /tmp/configBundle.tgz
# Befehl ausführen:
vim-cmd hostsvc/firmware/restore_config 0
# soll Problem des //UUID mismatch// überschrieben werden, dann besser mit 1:
vim-cmd hostsvc/firmware/restore_config 1
# System startet dann automatisch neu
# Vorsicht: ab ESXi 7.0 U2 //config// kann mit TPM verschlüsselt sein - geht also nur mit gleichem Host; also geht dann //UUID override// nicht, wenn TPM drin war;
3. Spezialfall: Was passiert nach Stromausfall
Es kann sein, dass nach Stromausfall ein ESXi-Host nicht startet, weil "Device Error" beim Booten auftritt und das Booten unterbricht. Ein ähnliches Szenario wird hier beschrieben.
In diesem Fall hat erstaunlicherweise Folgendes geholfen:
=> anderes Laufwerk im System zum Booten benutzen
=> darauf ein gleiches System installieren
=> Dateien von der BOOTBANK des neuen auf die des alten drüber kopieren
Dabei müssen einfach die Module identifiziert werden, die beschädigt sind - sonst fährt das Ding wieder hoch...=> darauf ein gleiches System installieren
=> Dateien von der BOOTBANK des neuen auf die des alten drüber kopieren
Auf dieser Seite sind keine Kommentare vorhanden
