===== Datenrettung =====
== Hilfe in unterschiedlichen Situationen von Datenverlust ==


//work in progress//

Vorerst nur nützliche Befehle:

((1)) 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.
	
	((2)) ##ddrescue## im Einsatz
	Wie benutzt man es:
	%%(perl)
# 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

%%



((1)) Datenrettung aus ESXi-Datenträgern
%%(perl)
# 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/ 
%%


((1)) 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:
%%(perl)
# 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 
%%

	((2)) Vorbeugen
	Die Konfiguration eines ESXi-Systems sollte ab und zu gespeichert werden (nach jeder wichtigeren Änderung?). Dies geht mit der Konsole so:
	%%(perl)
# 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
%%
	((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:
	%%(perl)
# 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;	
%%
	
	((2)) 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 [[https://community.spiceworks.com/topic/2325309-esxi-7-0b-fails-to-boot-after-power-outage-blackout 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...