There are various issues on ZFS native encryption. ZFS native encryption has been especially buggy when raw encrypted zfs snapshots are being sent or received.<p>https://github.com/openzfs/zfs/issues/11679<p>https://github.com/openzfs/zfs/issues/15989<p>https://github.com/openzfs/zfs/issues/15924<p>https://github.com/openzfs/zfs/labels/Component%3A%20Encryption<p>https://www.reddit.com/r/zfs/comments/10n8fsn/does_openzfs_have_a_new_developer_for_the_native/<p>On https://github.com/openzfs/openzfs-docs/issues/494
people unanimously agree that zfs native encryption is broken especially when sending or receiving raw encrypted zfs snapshots, and they blame the zfs leadership for refusing to admit that zfs native encryption is buggy because admitting that it is buggy is bad for the reputation of zfs.<p>zfs native encryption has been fine for local usage on my machine, but I have never attempted to send raw encrypted zfs snapshots due to numerous warnings.<p>Thus, I want to offer alternatives to zfs native encryption.<p>1. If your zfs pool is not large, LUKS is going to be faster than zfs native encryption. I don't know whether LUKS is going to be still faster if zfs pool contains many disks. ZFS native encryption can be as fast as LUKS or faster than LUKS, but it is not for now.<p>2. For making incremental encrypted backups, I recommend restic. Restic can make incremental encrypted snapshots of ZFS snapshots. You can delete any restic incremental snapshots without losing data in other snapshots. Restic 0.17 started supporting RESTIC_FEATURES=device-id-for-hardlinks which supports backing up $ZFS-MOUNTPOINT/.zfs/snapshot/$SNAPSHOT-NAME efficiently. Restic 0.18 will remove device-id-for-hardlinks feature flag and support .zfs/snapshot directories efficiently witout any feature flag. If you want to back up zfs dataset, you can take restic ZFS snapshot, back up .zfs/snapshot/restic as a new restic snapshot, and delete restic ZFS snapshot after backing it up. In this way, restic doesn't need to know about local sanoid ZFS snapshots which are independent from restic snapshots.<p>Restic supports compression, encryption, and deduplication. Thus, you can send incremental encrypted backups to untrusted machines. For remote backups, you can use amazon cloud storage, https://rsync.net, https://zfs.rent, and other cloud storage services. I don't have any association with any of these services. I don't recommend any. Do your own research if you want to pick a cloud storage provider.
> On <a href="https://github.com/openzfs/openzfs-docs/issues/494">https://github.com/openzfs/openzfs-docs/issues/494</a> people unanimously agree that zfs native encryption is broken especially when sending or receiving raw encrypted zfs snapshots, and they blame the zfs leadership for refusing to admit that zfs native encryption is buggy because admitting that it is buggy is bad for the reputation of zfs.<p>More details on this can be found in a gist from the same author (keep in mind he's a well known zfs commmiter).<p><a href="https://gist.github.com/rincebrain/622ee4991732774037ff44c6768085ab#encryption" rel="nofollow">https://gist.github.com/rincebrain/622ee4991732774037ff44c67...</a>
Thanks for the heads up. I am using regular ZFS on LUKS already. Seconded restic. I researched many backup systems and also appreciate how nice restic is, especially with its compression support nowadays.
I ran into a short period of time where occasionally sending a raw native-encryption snapshot would fail, but that was the only error, and deleting the failed snapshot resolved the error. Presumably the issue with quotas. That was fixed for me over a year ago and I have half a dozen volumes being snapshotted and sent hourly to three destinations with no errors.<p>This is on Debian with default kernels and ZoL versions.<p>I'd still prefer a bit more stability from native encryption.
I've always felt a little nervous about encrypting backups. The point of the backup is something has gone wrong and you want to get the data back. You don't really want stray bit errors to cascade across vast swathes of the data. Encrypt in transit sure, but maybe not when laying down the bit pattern on the medium at the other end.