When we developed synex-zfs-installer for Synex Server 13 R1, the goal was clear: offer ZFS as a storage option without the limitations of the traditional Debian Installer. That first version fulfilled its purpose, but during development we identified a similar opportunity with BTRFS: the predefined subvolumes we implemented for ZFS had the same potential value in a filesystem that shares that philosophy of flexible management.
From ZFS to a comprehensive alternative
The starting point was BTRFS. If we already had the logic to configure predefined storage structures with ZFS, extending it to BTRFS was a natural progression. Both filesystems share similar concepts: native snapshots, subvolume or dataset management, and differentiated policies by data type.
Once BTRFS was incorporated, the question was inevitable: does it make sense to offer only these two filesystems? EXT4 and XFS remain perfectly valid options for many server scenarios. Including them completed the spectrum of alternatives and turned the installer into a comprehensive option for those who prefer that path.
The result is synex-installer: a tool that started focused on ZFS and evolved to cover the four main filesystems. It does not replace the Debian Installer, which remains available for those accustomed to that workflow. It simply offers an alternative oriented toward agility, with predefined configurations where it makes sense and flexibility where it’s needed.
BTRFS: predefined structure for production
BTRFS shares with ZFS the philosophy of a modern filesystem: native snapshots, data checksums, and flexible storage management. For administrators familiar with these concepts but who prefer to stay within the standard Linux tooling ecosystem, it represents a coherent alternative.
The installer configures BTRFS with a subvolume structure designed for server environments. This separation allows differentiated snapshot policies according to data type: the base system can be reverted independently of logs, cache directories can be excluded from backups, and user data maintains its own recovery timeline.
The configuration comes predefined because experience shows that most deployments benefit from the same base structure. Those who need something different can always adjust post-installation, but starting from a solid configuration reduces errors and accelerates time to production.
EXT4 and XFS: full control through interactive partitioning
There are scenarios where the traditional approach is exactly what’s appropriate. EXT4 has been proving itself in production for decades, with mature recovery tools and predictable behavior. XFS offers optimized performance for specific workloads and proven scalability for large filesystems.
For these filesystems, the installer presents a different flow: interactive partitioning where the administrator defines the structure according to their specific needs. Mount points, partition sizes, optional swap inclusion: each decision remains in the hands of those who know the deployment requirements.
This approach respects an important premise: not all servers are the same. A database server may need a dedicated partition for data with specific characteristics. A web server may benefit from separating system logs. The installer provides the tools to implement these decisions without imposing a predetermined structure.
Four options, one coherent flow
The initial menu presents the alternatives directly: ZFS, BTRFS, EXT4, or XFS. Each option has its strengths, and the choice depends on the specific implementation context. What remains constant is the experience: clear prompts, validations at each step, and the ability to review before confirming destructive changes.
For those who prefer the traditional Debian Installer flow, that option remains available. synex-installer exists as an alternative for administrators seeking a more direct process, especially when the predefined configurations of ZFS or BTRFS align with their needs.
Next steps
In the next post, we will address the encryption options implemented for each filesystem, explaining the technical decisions behind each approach and how they integrate into the installation flow.
The idea behind these posts is to share not only what was implemented, but the reasoning that guided each decision. Developing an installer involves constant trade-offs between flexibility and simplicity, between advanced options and accessibility. Documenting that process may prove useful for those facing similar decisions in their own projects.
These improvements will be part of Synex Server 13 R2. Synex Server 13 R1 is available for download from here.