[HN Gopher] Mind the encryptionroot: How to save your data when ...
       ___________________________________________________________________
        
       Mind the encryptionroot: How to save your data when ZFS loses its
       mind
        
       Author : 6581
       Score  : 33 points
       Date   : 2025-09-30 20:58 UTC (2 hours ago)
        
 (HTM) web link (sambowman.tech)
 (TXT) w3m dump (sambowman.tech)
        
       | wkat4242 wrote:
       | > Lesson: Test backups continuously so you get immediate feedback
       | when they break.
       | 
       | This is a very old lesson that should have been learned by now :)
       | 
       | But yeah the rest of the points are interesting.
       | 
       | FWIW I rarely use ZFS native encryption. Practically always I use
       | it on top of cryptsetup (which is a frontend for LUKS) on Linux,
       | and GELI on FreeBSD. It's a practice from the time ZFS didn't
       | support encryption and these days I just keep doing what I know.
        
         | GauntletWizard wrote:
         | I really love ZFS Native encryption, but this is the big
         | problem with it. I use ZFS Raw Sends to store my backups
         | incrementally in a cloud I trust, but not enough to have raw
         | access to my files. ZFS has great attributes there,
         | theoretically - I can send delta updates of my filesystems, and
         | the receiver never has they keys to decrypt them.
         | 
         | I've used this in practice for many years (2020), and aside
         | from encountering exactly this issue (though thankfully I _did_
         | have a bookmark already in place), it 's worked great. I've
         | tested restores from these snapshots fairly regularly (~
         | quarterly), and only once had an issue related to a migration -
         | I moved the source from one disk to another. This can have some
         | negative effects on encryptionroots, which I was able to
         | solve... But I really, really wish that ZFS tooling had better
         | answers to it, such as being able to explicitly create and
         | break these associations.
        
         | tom_alexander wrote:
         | I use native ZFS encryption because it makes it super easy to
         | share encrypted datasets across dual-booted operating systems.
         | AFAIK Linux does not support GELI and FreeBSD does not support
         | LUKS. DragonflyBSD supports LUKS but then no ZFS.
         | 
         | Also, that way I can have Linux and FreeBSD living on the same
         | pool, seamlessly sharing my free space, without losing the
         | ability to use encryption. Doing both LUKS and GELI would
         | requiring partitioning and giving each OS its own pool.
        
         | binwiederhier wrote:
         | ZFS encryption is much more space efficient than
         | dmcrypt+unencrypted ZFS when combined with zstd compression.
         | This is because it can do compress-then-encrypt instead of
         | encrypt-then-(not-really-)compress. It is also much much
         | faster.
         | 
         | Source: I work for a backup company that uses ZFS a lot.
        
       | kalaksi wrote:
       | I've used zfs and btrfs and while I haven't quite lost data, I
       | have also hit some unnerving pitfalls / sharp edges that have
       | confirmed that I should keep at least one copy using just LUKS +
       | ext4. I like the features but I think the more complicated
       | filesystems bring about other kind of risks.
        
       | chasing0entropy wrote:
       | Why zfs freak out is accepted as "normal" in a dev environment is
       | beyond me. I use storage spaces on a daily basis in production
       | and dev environment and have for nearly 10 years now and with
       | only marginal use of PowerShell I have been able to restore every
       | array I didn't destroy intentionally. This is the bare minimum I
       | expect out of an redundant array of any type regardless of its
       | speed or scalability promises.
        
       ___________________________________________________________________
       (page generated 2025-09-30 23:00 UTC)