The server has a pool full of sensitive, very important # zpool list We start from a standard 12.1-RELEASE # uname -aįreeBSD jambon-production-server 12.1-RELEASE FreeBSD 12.1-RELEASE r354233 GENERIC amd64 We're going to simulate a production server migrating to a newer release and migrating its data to the new ZFS. This means that we can now use manipulate ZFS snapshots without ever handling unencrypted data, and so we can make a backup server at a location we don't fully trust. With native ZFS encryption, OpenZFS moves the encryption to the actual file system implementation. This is good enough if all part of the infrastructure is present and managed in a trusted location and all networks between the two are reliable. However, when moving datasets between systems, ZFS snapshots are still transmitted unencrypted, and the receiving server is responsible for encrypting and storing the data in a proper way.
This is working great, with great performance. Basically, a new layer is added to the system, which exposes a new block device where ZFS can be used on top. The most common way of doing it was with GELI. I always ensure that people who steal my hard drives can never access my data.Įncrypting ZFS pools has been possible for a while now. There is one feature I'm really interested in: encryption at rest. Right now it's possible to try OpenZFS alongside FreeBSD's ZFS distribution by building it from the port collection. When it's released, version 13 will have moved to OpenZFS. IntroductionįreeBSD is moving to OpenZFS. Making a backup server which receives incremental updates but can never decrypt the data.