Skip to content

ZFS encryption recovery: lastvet-imaging

Status: Operational runbook (August 2026). Canonical copy lives in git; mirror on the Proxmox host at /root/README-zfs-recovery.md for rescue when git is unavailable.

Encrypted dataset

Property Value
Pool tank-bulk
Encrypted parent tank-bulk/encrypted-lastvet-imaging
Encryption aes-256-gcm
Keyformat raw (32 bytes)
Keylocation file:///etc/zfs/lastvet-imaging.key

Auto-unlock

Handled by /etc/systemd/system/zfs-load-key-all.service (runs zfs load-key -a at boot, after zfs-import.target, before zfs-mount.service and zfs-volumes.target).

Recovery from lost /etc/zfs/lastvet-imaging.key

The key backup is in Bitwarden Secrets Manager, lastvet project:

Field Value
Secret name LASTVET_R940_ZFS_IMAGING_KEY
Format base64-encoded 32 bytes

Restore procedure

  1. On this host or any rescue system with access to Bitwarden and the ZFS pool:
ssh <bws-configured-host> \
  'bws secret list | jq -r ".[] | select(.key == \"LASTVET_R940_ZFS_IMAGING_KEY\") | .value"' \
  | base64 -d | sudo tee /etc/zfs/lastvet-imaging.key >/dev/null
sudo chmod 400 /etc/zfs/lastvet-imaging.key
sudo chown root:root /etc/zfs/lastvet-imaging.key
  1. Load the key and mount:
sudo zfs load-key tank-bulk/encrypted-lastvet-imaging
  1. On next boot, zfs-load-key-all.service picks up the key file automatically.

Recovery if hypervisor is destroyed

  1. Import the pool on a new Proxmox host (physical drives attached):
zpool import tank-bulk

  1. Encrypted datasets show keystatus=unavailable until the key file is restored (procedure above).

  2. Re-create zfs-load-key-all.service and any MinIO / VM mount units per R940 platform architecture and LastVet migration plan.