guglportfolio.blogg.se

Openzfs native encryption
Openzfs native encryption







openzfs native encryption openzfs native encryption
  1. #OPENZFS NATIVE ENCRYPTION FULL#
  2. #OPENZFS NATIVE ENCRYPTION PASSWORD#
  3. #OPENZFS NATIVE ENCRYPTION OFFLINE#

Backup data is directly streamed to external disks without temporary storage on extbackup server.External disks should only get decrypted during a backup run and getting encrypted/unmounted right afterwards.

#OPENZFS NATIVE ENCRYPTION PASSWORD#

  • Unlock password for those keys should only be used as a 2nd factor / seed, so encryption security does not depend on its length.
  • Both ZFS encryption key and SSH private key should not be required to be stored in any password manager or anywhere else.
  • #OPENZFS NATIVE ENCRYPTION FULL#

  • SSH access on remote backup server is strictly limited to pve-zsync operations, without providing a full shell.
  • SSH private key to connect to backup is not stored anywhere on extbackup in plaintext, only getting generated at runtime.
  • We choose PVE-zsync as simple backup tool / replication manager
  • Snapshot-based backup for optimal performance: Backup data is pulled from backup over SSH, using zfs send|recv.
  • ZFS encryption key not stored anywhere on disk, only generated at runtime.
  • External drives fully encrypted using ZFS native encryption (preferred over LUKS for better handling and easier setup).
  • System is installed on internal SSD, external drives attached over USB 3 or eSATA.
  • No backup data should ever be stored (not even temporarily!) on rpool (system partition), only on encrypted external drives.
  • System: Proxmox VE for well-maintained OpenZFS and PVE-zsync support.
  • Hardware: Payable but reliable fanless system that could be mounted to any office desk.
  • We have the following – from a security point of view – rather strict requirements: Let's call your main backup server backup and the one we are going to set up here extbackup. But as it needs to pull data frequently, its storage is always available and not getting detached. Preferably, your main backup server would also be offsite.

    #OPENZFS NATIVE ENCRYPTION OFFLINE#

    So, we are talking about offline backups in addition to the fact having this server offsite - at a different location than your main backup server. We would now like to set up a second offsite backup server that just cares about storing data to an encrypted external drive and after each backup run, you are going to physically detach that drive. Backup data is stored in ZFS datasets, ideally as individual datasets per full-system backup for each host. Let's assume you already have an existing backup server that is connected to the internet 24/7 and runs daily/weekly/monthly backup jobs. So let's go ahead and built that thing from scratch on a fresh 2021 stack! What we want to accomplish: A performant and secure backup solution based on ZFS, using zfs send|recv for efficient data transfer, and ZFS native encryption to secure our external drives. Also, LUKS encryption may be a bit low level and inflexible. As we all know, transferring data with rsync can get horribly slow and blow up your I/O if you're transferring millions of small files. Back then, I was using rsync over SSH to pull backup data, and LUKS encryption as full disk encryption for the external drives. Let's improve our Simple and Secure External Backup solution I have published back in 2018.









    Openzfs native encryption