Running 25.10.1, I created a new pool. The original pool was unencrypted, with a flat dataset hierarchy: each one lived in the pool’s root, individually encrypted. When I replicated my datasets back, I did so into a newly added tier, with storage1 now a dataset nested in the root pool, rather than being the root:
gen8 (original) gen8 (now)
------------ ------------
storage1 (unencrypted) pool (unencrypted)
∟ nas (unlocked) ∟ storage1 (unencrypted)
∟ ... ∟ nas (unlocked)
∟ scripts (unlocked) ∟ ...
∟ n40l_backup (unencrypted) ∟ scripts (unlocked)
∟ nas (locked) ∟ n40l_backup (unencrypted)
∟ scripts (locked) ∟ nas (locked)
∟ scripts (locked)
The hierarchical change enables me to take a single snapshot of the storage1 dataset with recursion (while explicitly not capturing the n40l_backup branch of datasets). I’m able to take the simplified snapshot, and tie multiple replication tasks to the recursive snapshots within it.
My desire is to have a single replication task that uses pool/storage1 recursively as the source, sent to my reciprocal offsite box, n40l. Currently the replication tasks are still done per-dataset, with each one living in the encrypted root on n40l; I want to consolidate that to be a tree similar to my gen8 box, with the ‘remote’ backup datasets locked on the ‘local’ pool:
n40l (as-is) n40l (intended)
------------ ------------
pool (encrypted) pool (encrypted)
∟ gen8_nas_backup (locked) ∟ gen8_backup (locked)
∟ ... ∟ nas (locked)
∟ gen8_scripts_backup (locked) ∟ ...
∟ nas (unlocked by ancestor) ∟ scripts (locked)
∟ scripts (unlocked by ancestor) ∟ nas (unlocked by ancestor)
∟ scripts (unlocked by ancestor)
The idea is to not have to update the replication task every time I add another dataset. All of my stuff in a single branch, all of the other box’s stuff in another. One snapshot task, one replication task, everything covered with no decrypt key stored on the remote box.
Since I cannot recursively replicate the whole pool/storage1 to a remote encrypted pool due to the base storage1 being unencrypted, is my recourse to
- continue dataset-by-dataset replication tasks, which can/does work
local, encrypted datasets remote target, encrypted pool
------------ ------------
pool/storage1/nas >> pool/gen8_nas_backup (is locked)
pool/storage1/immich >> pool/gen8_immich_backup (is locked)
pool/storage1/scripts >> pool/gen8_scripts_backup (is locked)
- or the three-step dance of
- locally replicate encrypted datasets without dataset properties to make unencrypted copies (
pool/storage1/nas>>pool/storage1/nas2) - then (because the possibility of ghosts remaining after a
zfs renamescares me) delete originals and replicate again with include dataset properties to get the names back (pool/storage1/nas2>>pool/storage1/nas) - replicate the fully unencrypted
pool/storage1to the remote target with replication task encryption enabled with a passphrase (testing using hex encryption saw the key sent/available to the destination and the dataset unlocked; passphrase at least lets me re-lock it) - (alternately, replicate one more time locally, with task encryption enabled, making all of them use the same encryption root, then replicate that without task encryption)
- locally replicate encrypted datasets without dataset properties to make unencrypted copies (
?
Copy replicating without dataset properties into a dataset other than storage1 was stripping the acl permissions… replicating within storage1 preserved them. Odd to me, but it worked. Permissions preservation is important because they are many, and granular. I don’t want to recreate them by hand.
I made a test set of empty datasets, unencrypted the whole way down, and replicated to the remote box, using replication task encryption. After locking the dataset on the remote box, the whole branch is locked, as I want. I’d really prefer hex key because I know those are in the config backup, and I can recover them if needed. Is the passphrase to an encrypted dataset saved, and is that dependent on the dataset being unlocked?