michaelcarlos
In practice, Reddit is not a consistently reliable source for technical guidance. Much of the information shared there is inaccurate, incomplete, or rooted in personal anecdotes rather than systematic testing or documented behavior. This becomes especially problematic in areas like system encryption, where flawed assumptions can lead to serious consequences, including performance degradation, backup failures, or data loss. Even the FreeBSD Handbook does not adequately address the operational concerns involved in using GELI and ZFS native encryption together. It often focuses on initial implementation without fully explaining the long-term implications for system administration. Configuring encryption is only the beginning, maintaining it reliably over time is the real challenge. :-)
Many users have asked about combining GELI and ZFS native encryption on GhostBSD. While both methods offer strong encryption, using them together comes with trade-offs, especially on older systems, which make up the majority of GhostBSD installations. Most users run GhostBSD on machines with around 4GB of RAM and 2 CPU cores, often without hardware encryption acceleration. With that in mind, here’s what users should consider:
GELI encrypts the entire disk or partition before ZFS is even loaded. This provides full-disk encryption, including swap and non-ZFS areas, which is useful for physical security. However, GELI performs all encryption in software unless your CPU supports AES-NI, and this can significantly impact performance on older hardware. Backups made with zfs send or beadm work normally because ZFS operates on a decrypted view of the device once GELI is unlocked, but the resulting backups are not encrypted unless you write them to another encrypted destination. If you plan to move these boot environments to another system, you'll need to either replicate your GELI setup or decrypt and re-encrypt the data manually.
ZFS native encryption works at the dataset level and allows you to encrypt boot environments individually under zroot/ROOT/. It integrates well with features like snapshots and send/receive. You can create encrypted backups that preserve keys and metadata using zfs send -w. This makes it easier to replicate or restore boot environments across systems, provided you manage your keys properly. That said, encrypted root datasets currently require manual configuration to load keys at boot, since the FreeBSD bootloader doesn’t yet handle this natively. Also, on lower-end hardware, ZFS encryption may introduce noticeable overhead, particularly if you're using multiple encrypted datasets.
Using both GELI and ZFS encryption together creates a doubly encrypted system. While possible, this setup increases CPU load, slows down I/O, and makes recovery and backups more complex due to the need to manage both device-level and dataset-level keys. For most GhostBSD users, this added complexity outweighs any theoretical security benefits.
Summary:
If your priority is simple full-disk protection, GELI is fine, just be aware of the performance hit and portability limitations. If you want better backup flexibility and per-dataset encryption control, ZFS native encryption is the better option, especially if you’re managing boot environments and remote replication. For most users on older hardware, using both is not recommended.
