In the previous post, we described how synex-installer evolved to support four filesystems. The next step was natural: if the installer already manages storage configuration, it makes sense for it to also offer encryption as part of the process. The moment of installation is when the storage architecture is defined, and encryption is part of that architecture.
Encryption as part of the installation flow
The decision to include encryption in the installer responds to a reality: in many environments, data-at-rest protection is not optional. Compliance regulations, internal security policies, or simply best practices dictate that server disks must be encrypted. When this is resolved during installation, the server enters production already protected.
The challenge was that each filesystem has different characteristics, and forcing a single encryption method for all of them made no technical sense. The solution was to adapt the approach according to the chosen filesystem, leveraging native capabilities where they exist and using standard tools where they are the best option.
ZFS: native encryption with AES-256-GCM
ZFS includes encryption as an integrated feature of the filesystem. It is not an external layer added on top, but part of the architecture: data is encrypted before being written to the pool, and integrity checksums operate on the encrypted data. This integration means that advanced ZFS features, such as snapshots and replication, work transparently with encrypted data.
The installer uses AES-256-GCM when encryption is enabled in ZFS. The passphrase is requested during installation and configured at the pool level, with datasets inheriting the configuration automatically. The only technical requirement is that /boot remains unencrypted on a separate partition, as GRUB needs access to the kernel before the encrypted pool can be unlocked.
This was the most straightforward option to implement: ZFS already has everything solved, we just had to expose it in the installation flow and ensure the boot configuration worked correctly.
BTRFS: LUKS2 as an external container
BTRFS does not include native encryption. The standard solution in the Linux ecosystem is LUKS, which operates as an encryption layer beneath the filesystem. Data passes through LUKS before reaching the disk, and BTRFS operates without knowing it’s on an encrypted volume.
For BTRFS, we chose LUKS2 directly on the partition, without intermediate layers. The reason is that BTRFS already provides flexible storage management through subvolumes: it doesn’t need LVM to resize or reorganize space.
The flow is simple: the installer creates the LUKS2 container, formats with BTRFS inside, and configures the subvolumes just like in an unencrypted installation. The /boot partition remains unencrypted for the same reason as in ZFS: the bootloader needs access before unlocking.
EXT4 and XFS: LUKS2 with LVM for flexibility
EXT4 and XFS are traditional filesystems without integrated volume management. A partition is a partition: fixed size, with no possibility of dynamic adjustment. On a server where requirements may change, that rigidity is a limitation.
This is where LVM adds value. By placing LVM inside the LUKS2 container, we get logical volumes that can be resized, extended, or reorganized without touching the encryption. A single LUKS container protects all storage, while LVM provides the flexibility that these filesystems don’t have natively.
The installer configures the complete scheme: LUKS2 partition, physical volume, volume group, and logical volumes according to what the administrator defines in the interactive partitioning. One passphrase unlocks all storage, and from there each logical volume operates independently.
This decision adds a layer of complexity, but it’s justified complexity. Without LVM, the administrator would be left with fixed-size encrypted partitions, losing flexibility on servers where space requirements may evolve.
Same question, different answers
The three approaches respond to the same need, protecting data at rest, but in ways adapted to each context. ZFS already has the solution integrated; using it was obvious. BTRFS needs LUKS but not LVM. EXT4 and XFS need both to avoid sacrificing flexibility.
From the user’s perspective, the experience is consistent: a question about whether to enable encryption, a passphrase to enter, and the installer takes care of the rest. The technical differences remain abstracted behind a uniform flow.
Next steps
This post closes the series on the development of synex-installer. Together, the three posts document the evolution from an installer focused on ZFS to a comprehensive tool with multi-filesystem support and encryption adapted to each option.
Synex Server 13 R2 will incorporate all these improvements. The tentative release date is the week of February 16. Meanwhile, Synex Server 13 R1 is available for download from here.