Datenrettung
Hilfe in unterschiedlichen Situationen von Datenverlust
work in progress
Vorerst nur nützliche Befehle:
A. Datenrettung allgemein
Rettung der Daten von einem beschädigten Datenträger ist mit ddrescue häufig einfacher, als man denkt. Aber auch andere Mechanismen sind dabei sehr hilfreich.
1. ddrescue im Einsatz
Wie benutzt man es:
# ddrescue + vmfs tools installieren - auf einem Debian-System:
apt install gddrescue
# 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
apt install gddrescue
# 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
B. 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/
C. 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
