ZFS geli pw correct, zpool empty?

Dear all, I'm puzzled by the following, here's what happened:

(1) I reinstalled FreeBSD (I wanted to start from scratch trying Wayland / Hyprland instead of KDE (that was running like a charm)). But, before I reinstalled, I physically disconnected my data disk hdd: a geli-encrypted zpool called 'zstorage' (ada1p1)
(2) After setting up the system, I physically reconnected the disk, booted in the system, and decrypted the disk with the following geli command:
geli attach ada1p1
This proceeded without problems
(3) then I got confused trying to mount it using zpool, partly read the man page, tried a bunch of commands like:
zpool create zstorage
zpool create zstorage ada1p1
zpool create -f zstorage ada1p1

After these commands, I found the mount point /zstorage was there, but the disk was empty (also confirmed by df -h)

After a stressful reboot, I fired up a browser on my phone to read some more, and realized I should not have been running the create commands, but the import command after geli attach instead:
zpool import zstorage
To my horror, the disk was still empty...

So, now my question: I seem to be able to decrypt with geli attach just fine (so the data is fine?), but after the zpool commands the disk seems to be emtpy. Is it possible that one of the issued zpool commands destroyed the data on the disk? Please help!
 
pool create -f zstorage ada1p1
This command effectively nuked whatever was on that disk. It created a new zstorage pool, overwriting the old.

I seem to be able to decrypt with geli attach just fine (so the data is fine?)
Maybe, maybe not. Some parts were definitely overwritten and are likely not recoverable.

When you do zpool import it's probably going to show that new zpool, not the old. You could try zpool import -d /dev/ada1p1.eli and force it to look at the geli encrypted partition. But I fear your data may be lost.
 
Thanks for your fast and complete reply, SirDice! It also helped me understand that a zpool is not just a 'container' structure that mounts a partition, block device, array, etc. but more that of a proper named filesystem of sorts...

I will try your suggestion as soon as I'm in front of that computer again.

I previously nuked the 'data' on a dm_crypt encrypted disk (with an ext4 file system inside), but in that case only the LUKS header was overwritten (while progressing a little bit too far in partman of the Debian Installer). These are painful mistakes in case one doesn't have any data backups.

That quote in your signature is spot-on: Experience is something you don't get until just after you need it.
 
Back
Top