Einen Monat später sollte die Eingebung zur Rettung der Daten auf der Ursprungsplatte kommen. Mittlerweile waren die noch vorhandenen VMs auf einer großen Platte mit Debian als Host System umgezogen. Nach der Datenrettung wird dort zusammen mit der Ursprungsplatte ein RAID gebaut. Es wurde nochmal kniffelig.
Der Plan: Auf einer kleinen alten Platte wurde ein frisches FreeBSD aufgesetzt. Die mit Geli verschlüsselte Ursprungsplatte mit ZFS als zweite Platte und die Zielplatte mit LVM als dritte angeschlossen. Und los als root:
kldload fuse.ko was dann eigentlich nicht gebraucht wurde, ich dachte ext4 und lvm2 gehören zusammen, ist es aber nicht. Oder doch? Ich weiß es nicht.
# kldload /boot/kernel/geom_linux_lvm.ko # cd /usr/ports/sysutils/fusefs-ext4fuse/ # make install clean # mkdir /mnt/linux # ext4fuse /dev/linux_lvm/volumegroup-logicalvolume /mnt/linux
Wobei volumegroup-logicalvolume durch den entsprechenden Eintrag in /dev geändert wurde.
Toll, die Zielplatte war eingebunden. Leider kam ich mit der Ursprungsplatte genau so wenig weiter, wie einen Monat zuvor. Die Idee, im unverschlüsselten bootpool nochmal zu gucken, brachte mich weiter. So wie ich den Key rauskopiert hatte, konnte ich diese nochmal einbinden.
zfs import -N -f bootpool # forcefully import bootpool, but don’t mount it. zfs set mountpoint=/tmp/bootpool bootpool zfs mount bootpool
In /boot/loader.conf sollte alles benötigte stehen:
geom_eli_load=”YES” geli_da0p4_keyfile0_load=”YES” geli_da0p4_keyfile0_type=”da0p4:geli_keyfile0″ geli_da0p4_keyfile0_name=”/boot/encryption.key” vfs.root.mountfrom=”zfs:zroot” zfs_load=”YES”
Das sollte auf die Bootplatte, dachte ich, da0p4 auf da1p4 geändert natürlich. Im Eifer des Gefechts hatte ich vergessen, für LVM Einbindung der Zielplatte einzurichten. Aber das Hochfahren war exakt so, wie vor dem Upgrade Anfang September.
Ich war wieder auf dem ursprünglichen System!
Weil ich die LVM Einbindung vergessen hatte, war die Zielplatte zunächst nicht erreichbar. Ich kam nicht mehr in /boot. Das Kuriose nun war, die Ursprungsplatte konnte alleine wegen dem kaputten init nicht starten. Die frische FreeBSD Platte konnte nun auch nicht mehr alleine starten, wegen den loader.conf Einträgen. Beide Platten zusammen ermöglichten jetzt das Starten des ursprünglichen Systems.
Ich entschloss mich, das Debian normal zu starten, damit die VMs auch wieder online waren. Die beiden symbiotischen FreeBSD Platten kamen in einen Ersatz Rechner. Nun konnte, zwar langsam über Netzwerk, die Datenrettung beginnen. Und mit dem Vorteil, kopieren der Daten zeitgleich mit den laufenden VMs.
Gollum hatte wieder Glück gehabt.