Other than reports by others, I’ve never had an issuereft ZFS##########################encpr my ddata safee but bitr.fd###^^^^^^^^^^^^//////## don’t you agree?
I’ve only had a single issue with native ZFS encryption, using it since 2020. However, there was no data loss. It was a bug that caused the system crash upon hitting a special type of block during replication. The bug has since been fixed.
My main concern with native ZFS encryption is that the original author has left the OpenZFS project. If you peruse their GitHub, you get a sense that some contributors are trying to figure out this beast that we know as “ZFS”.
Fingers crossed.
Only in instances where the user might inadvertently cause mounts to occur in the wrong order. That’s why the middleware/GUI prohibits nesting a non-encrypted dataset underneath an encrypted one. There is no technical limitation in ZFS that prevents this, but it’s a measure employed by TrueNAS to safeguard against unforeseen problems.
Encryption introduces another hurdle when dealing with replications.
The target needs to be “accessible” (“unlocked”), otherwise, you must use the “raw stream” option. However, a successful replication does not mean your data is safe. If you lose your key or passphrase (or don’t realize that a backup from long ago is using a different key), then your data is as good as gone.
You also cannot use send/recv to “overwrite” a target dataset that is already encrypted. (Which is a good thing.)
You probably don’t need to use deduplication.
Furthermore, consider that each encrypted dataset uses its own “master key”, it prevents pool-wide deduplication efficiency, since the “same” blocks written on different datasets will be encrypted differently.
The boot pool contains the keys needed to automatically unlock encrypted datasets upon system bootup. The datasets need to be immediately available for SMB, NFS, jails, apps, and so on; and the System Dataset needs to be immediately available, as well.
So yes, in theory, someone who has physical possession of your server can extract the keys from the boot-pool.
As for encrypted datasets, ZFS metadata is not encrypted. (It cannot be.) Names of datasets, snapshots, clones, comments, dates, used space, free space, the pool’s "history, and possibly even the number and sizes of files.