Learn DragonFlyBSD - HAMMER2 Snapshot, Dedup & Encryption

#Introduction

In episode 8 you understood PFS, volumes, and HAMMER2 properties — the foundations that make this filesystem unique. Now we pick up the features people search for most: snapshots, deduplication, and encryption. These are the three biggest reasons someone chooses DragonFlyBSD as a storage platform.

Imagine a snapshot as a polaroid of your warehouse at a single moment: the entire contents — every file, every byte — recorded exactly, without using up double the space. Deduplication is the staff member who finds twin items and stores them only once. Encryption is the padlock that ensures the warehouse contents can only be read with the right key.

#Snapshots

#Creating a Snapshot

HAMMER2 snapshots are made with hammer2 snapshot. Every snapshot is a new PFS that records the state of the filesystem at a particular point in time:

Create a snapshot on a PFS

hammer2 snapshot /mnt/data
hammer2 pfs-list /mnt/data

The first command creates a snapshot with a dated default name; the second shows all PFSes including the newly created snapshot. Every snapshot can be mounted, accessed, even rolled back.

#Managing the PFS and Snapshot List

Show details of all PFSes:

List and show PFS details

hammer2 pfs-list /mnt/data
hammer2 pfs-destroy /mnt/data/.snapshot/2026.08.03-1200

pfs-destroy removes a PFS or snapshot. Be careful — this operation is permanent. Always verify the snapshot name before deleting.

#Rollback

Rollback returns the filesystem to the state recorded in a snapshot. It's the lifesaver when data is deleted or corrupted:

Roll back to a snapshot

hammer2 snapshot /mnt/data
umount /mnt/data
hammer2 rollback /mnt/data@ROLLBACK
mount_hammer2 /mnt/data /mnt/data

The safe pattern: create a new snapshot first (if possible), unmount, perform the rollback, then remount. Present-day data won't be lost because it's still stored as a snapshot.

Warning

Rollback changes the active PFS to the snapshot state. Processes writing to the filesystem must be stopped first — that's why umount happens before the rollback. In production, do this in a maintenance window.

#Clones

A clone is a copy of a PFS that can be mounted in parallel — useful for development, staging, or data analysis without touching the original data:

Create a clone from a snapshot

hammer2 snapshot /mnt/data
hammer2 clone /mnt/data@CLONE /mnt/data/.snapshots/clone-1
mount_hammer2 /mnt/data/.snapshots/clone-1 /mnt/clone

With a clone, you can experiment freely on /mnt/clone — changes there don't affect the original PFS.

#Deduplication

#Block Deduplication

Deduplication finds identical data blocks and stores them only once, significantly reducing space usage — especially for VM images, backups, and package repositories that contain lots of repeated data. HAMMER2 runs dedup via bulkfree or explicitly:

Run deduplication

hammer2 bulkfree /mnt/data

hammer2 bulkfree scans the filesystem, identifies identical blocks, and frees the duplicate space. This is a safe operation that can be scheduled regularly — we'll put it into practice as a cron job in episode 19.

#Dedup Strategy

Deduplication works best when data repeats on a large scale. Consider placing VM images, tar backups, and ISOs in a single deduplicated PFS — that way the savings really show. Unique data like logs and databases don't benefit much.

#Encryption

#Per-PFS Encryption

HAMMER2 supports per-PFS encryption. That means you can encrypt one PFS (for example sensitive data) while other PFSes remain plain. Enabling encryption:

Enable encryption on a PFS

hammer2 set-encrypted /mnt/data/sensitive

Once enabled, that PFS requires a key at mount time. Without the key, the data can't be read — perfect protection for stolen media or moved drives.

Danger

Encryption without a key means data locked forever. Store your PFS keys safely — for example in a password manager or a separate encrypted file. There's no backdoor in HAMMER2: losing the key is equivalent to losing the data.

#Encryption Practices

A practical pattern: separate data that needs encryption into its own PFS, enable encryption, and document how to mount with the key. For serious needs, consider a combination: per-PFS encryption for core data, scheduled snapshots for recovery, and off-site backups for disasters.

#Remote Mounting (Experimental, 6.4)

Release 6.4 brings experimental remote mounting of HAMMER2 — mounting a HAMMER2 filesystem from another host over the network, similar to the NFS concept but with HAMMER2 features:

Mount HAMMER2 remotely (experimental)

mount_hammer2 //host1/mnt/data /mnt/remote

This feature is young and labeled experimental — good for exploration, but don't make it the backbone of production before it matures. In episode 11 we'll also look at hammer2 send, which uses the snapshot model for data transfer.

#Closing

In this episode 9 you mastered HAMMER2's advanced features: creating snapshots with hammer2 snapshot, managing PFSes with pfs-list and pfs-destroy, rollback and clones, block deduplication with hammer2 bulkfree, per-PFS encryption with hammer2 set-encrypted, and getting to know the experimental remote mounting in 6.4.

Key takeaways:

Snapshots are point-in-time PFSes: hammer2 snapshot, pfs-list, and rollback are the basic cycle.
Clones give you an experimental copy without touching the original data.
Deduplication with hammer2 bulkfree saves space for repeated data.
Per-PFS encryption with hammer2 set-encrypted protects sensitive data; store keys safely.
Remote mounting in 6.4 is still experimental — use it with caution.

In the next episode, episode 10, we switch from storage to networking: networking & network configuration. You'll configure interfaces in /etc/rc.conf (DHCP and static), use ifconfig and route, lay out /etc/resolv.conf, then get to know the custom newbee network stack, interface aliases, VLAN, lagg bonding, bridge, and IPv6.