4 ms·
> So I'm in favor of native ZFS encryption due to its usability. Another reason to favour it is because if you do ZFS Send/Recieve to do incremental backups (l
by josteink 4y ago
> So I'm in favor of native ZFS encryption due to its usability.
Another reason to favour it is because if you do ZFS Send/Recieve to do incremental backups (like with rsync.net), you can backup your encrypted datasets to an off-site location without shipping the encryption keys.
That means you don't have to be afraid of your backups somehow resulting in breaking your confidentiality.
So you can still retain your incremental ZFS based backup-flow, and you don't have to change any tooling to use it. With LUKS you will either have to store your backups unencrypted, or you lose the ability to do incremental ZFS-based backups.
- dev_hugepages 4y agoThe LUKS headers doesn't contain the encryption keys, they're encrypted from the user's passphrase through a KDF. Additionally, you can make the LUKS header "detached" (external) see https://wiki.archlinux.org/title/Dm-crypt/Specialties#Encrypted_system_using_a_detached_LUKS_header https://wiki.archlinux.org/title/Dm-crypt/Specialties#Encryp...
- josteink 4y agoBut my point was that if you want to backup such a volume (the encrypted LUKS volume), you will have to backup the whole volume, and can't do incremental backup. If you want to do incremental ZFS send/recieve backups, you have to do it on the unencrypted ZFS volume, and thus your backup wont be encrypted. That is you can't have both encrypted and incremental backups at the same time. With native ZFS encryption you do get that.