Questions on Core to Scale upgrade with Geli removal

[pious_greek]

Hi All, I was hoping someone with more experience could verify the following procedure is sound....

I would like to migrate from TrueNAS Core 13.0-U5.3 to TrueNAS Scale. I have made appropriate backups of all config, keys, geli keys, offline replication, etc. My current Pool ("Tank") has the legacy Geli encryption, so I gather this adds a few additional steps.

Goals:

1. Remove the geli enycryption
2. Restore data to a new pool as well as datasets that have the zfs encryption.
3. upgrade core to scale

The steps I plan to take are as follows:

1. Create a temporary backup NAS (Backup_NAS). The backup NAS Pool will be created with zfs encryption.
2. Replicate the "Tank" pool to the backup NAS over local network. I will not use any encryption for the replication task.
   1. confirm replication task successful. use "fc" to compare the piped output of "dir /s" for each of the pools.
3. Delete the old Geli encrypted Tank pool.
4. Created a new zfs encyrpted Tank Pool.
5. Create a new replication task to replicate the Backup_NAS pool back to the TANK pool.
6. switch trains to truenas scale and upgrade via the gui.

Please let me know if there's an easier way or you see any flaws in the approach.

 

[winnielinnie]

Create a temporary backup NAS (Backup_NAS). The backup NAS Pool will be created with zfs encryption.

A key or passphrase?

Replicate the "Tank" pool to the backup NAS over local network. I will not use any encryption for the replication task.

Sure, but why not just "zfs send/recv" with the option to inherit the encryption of the Backup_NAS pool's root dataset? This can serve as your basis for ZFS enryption in the next step, where you send everything back to the new Tank pool.

The way ZFS is designed falls short of intuitively transferring one encrypted "pool" to another. You see, you cannot replace an encrypted dataset with another encrypted dataset "in place". This makes it tricky when dealing with encrypted root datasets.

That's why you'll have better luck "nesting" pseudo-roots under the actual root dataset, and just go from there.



If you want the least headaches, especially for SCALE, don't encrypt the root dataset. (Which means you choose not to encrypt the "pool"; which is misleading anyways.) Rather, create a pool without encryption, and simply use encryption for the pseudo-root and child datasets.

 

[pious_greek]

A key or passphrase?



Sure, but why not just "zfs send/recv" with the option to inherit the encryption of the Backup_NAS pool's root dataset? This can serve as your basis for ZFS enryption in the next step, where you send everything back to the new Tank pool.

The way ZFS is designed falls short of intuitively transferring one encrypted "pool" to another. You see, you cannot replace an encrypted dataset with another encrypted dataset "in place". This makes it tricky when dealing with encrypted root datasets.

That's why you'll have better luck "nesting" pseudo-roots under the actual root dataset, and just go from there.



If you want the least headaches, especially for SCALE, don't encrypt the root dataset. (Which means you choose not to encrypt the "pool"; which is misleading anyways.) Rather, create a pool without encryption, and simply use encryption for the pseudo-root and child datasets.

You were right on both counts, pseudo roots and zfs send/recv. Thanks for pointing me in the right direction.