Until zfs native encryption becomes fast and stable, use LUKS for local encryption and restic for encrypted incremental backups.

[amano-kenji]

Right now, zfs native encryption is slower than LUKS. It is also unstable and leads to kernel panics and various errors when sending or receiving raw encrypted zfs snapshots.

Thus, I propose LUKS for local encryption and restic for making encrypted incremental backups.

Restic stores file blocks and makes incremental snapshots. It can delete arbitrary restic snapshots without losing data just like zfs snapshots. It supports compression, deduplication, and encryption. Thus, you can store restic snapshots on untrusted remote machines. You can use amazon cloud storage, https://rsync.net/, https://zfs.rent/, and other cloud storage providers.

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.

[amotin]

Do you plan to pay us for the advertisement of your products while blaming ZFS for problems with no details?

[rincebrain]

Please, let's play nice in the sandbox, everyone.

I'm not thrilled about where this part of the project is either, as discussions have previously shown at length, but let's go for civil conversation.

[amano-kenji]

#12014 still reports that zfs encryption corrupts snapshots. Zfs native encryption isn't ready for production.

[lundman]

As someone who has used zfs native encryption for more than 10 years, and not once had issues with it, it is working very well. It plugs in the same as compression after all.
Now send/receive on the other hand has had many problems; remember -L anyone? Incremental send holes? Yep. I'm here to champion for renaming the issues from "native encryption is broken" to "send/recv is broken". All hail hyd^Wencryption!

[rincebrain]

Jorgen, if send/recv works reliably when not using native encryption, and if some of the bugs in native encryption can be triggered without using send/recv, the correct overarching description for the data points does not seem to be "send/recv is buggy".

[amano-kenji]

There is a possibility that some of those issues were caused by a lot of dust in computer case. I thought I had to replace RAM or GPU because they were problematic. After thoroughly eliminating dust in my computer case, errors in RAM and GPU went away.

I think dust is charged with electrons that zap computer parts.

Many errors will go away if you replace non-ECC RAM with ECC RAM or remove dust in your computer case.