There are a few issues and limitation when it comes to replicating unencrypted (or GELI encrypted) pool to the new pool with Native ZFS encryption.
The mechanism which is based on replication requires the data to be encrypted on the target by having the encryption ie passphrase stored on the target (remote TrueNAS in this case). The reason for it is that the raw transfer if possible with unencrypted dataset doesn't allow re-encryption or removal of the encryption on the target.
In order to replicate to a target (local or remote) while preventing the dataset to be unlocked is to use the -r (-raw) option which is only valid if the source pool or dataset is using the new native ZFS encryption.
The reason is explained in the link below:
From the OpenZFS documentation:
https://openzfs.github.io/openzfs-docs/man/master/8/zfs-send.8.html
If the source and target pool are based on the new native ZFS encryption, then the GUI will be able to perform replication but I have found also several limitations in it's implementation.
Recursive replication via GUI is extremely slow as it involves sending one snapshot per dataset using the (-i) option. It is done by replicating each dataset having the same snapshot date and name (which must also adhere to a very strict naming convention), then repeat the replication process by selecting the next snapshot and so on.
The operation would be significantly faster if the (-I) option was used with the "zfs send" command by simply letting ZFS handle the replication using the last and most recent snapshots.
As far as I could tell, TrueNAS is using Python zettarepl script to handle the snapshot managmeennt and replication which is shown while running htop and monitotry for any zfs transactions.
https://github.com/truenas/zettarepl/tree/master
The new ZFS encryption and replication procedure works great when performing a recursive replication (via CLI) as it preserves the "Unlock/Lock Child Dataset" to be at the top level.
If I try to perform a replication, one dataset at a time, I am able to replicate the encrypted dataset as raw stream and preserve the encryption mechanism and key or passphrase on the target, but rather than being able to decrypt the top level dataset and allow the children to be unlocked in a single step, each dataset must be unlocked individually.
I am still trying to figure out how to handle the replication of the dataset and allow the inheritence of the encryption to be taken from the higher level dataset. The OpenZFS documentation isn't really clear on the subject.
The mechanism which is based on replication requires the data to be encrypted on the target by having the encryption ie passphrase stored on the target (remote TrueNAS in this case). The reason for it is that the raw transfer if possible with unencrypted dataset doesn't allow re-encryption or removal of the encryption on the target.
In order to replicate to a target (local or remote) while preventing the dataset to be unlocked is to use the -r (-raw) option which is only valid if the source pool or dataset is using the new native ZFS encryption.
The reason is explained in the link below:
From the OpenZFS documentation:
https://openzfs.github.io/openzfs-docs/man/master/8/zfs-send.8.html
If the source and target pool are based on the new native ZFS encryption, then the GUI will be able to perform replication but I have found also several limitations in it's implementation.
Recursive replication via GUI is extremely slow as it involves sending one snapshot per dataset using the (-i) option. It is done by replicating each dataset having the same snapshot date and name (which must also adhere to a very strict naming convention), then repeat the replication process by selecting the next snapshot and so on.
The operation would be significantly faster if the (-I) option was used with the "zfs send" command by simply letting ZFS handle the replication using the last and most recent snapshots.
As far as I could tell, TrueNAS is using Python zettarepl script to handle the snapshot managmeennt and replication which is shown while running htop and monitotry for any zfs transactions.
https://github.com/truenas/zettarepl/tree/master
The new ZFS encryption and replication procedure works great when performing a recursive replication (via CLI) as it preserves the "Unlock/Lock Child Dataset" to be at the top level.
If I try to perform a replication, one dataset at a time, I am able to replicate the encrypted dataset as raw stream and preserve the encryption mechanism and key or passphrase on the target, but rather than being able to decrypt the top level dataset and allow the children to be unlocked in a single step, each dataset must be unlocked individually.
I am still trying to figure out how to handle the replication of the dataset and allow the inheritence of the encryption to be taken from the higher level dataset. The OpenZFS documentation isn't really clear on the subject.
