Learn DragonFlyBSD - Data Management & Backup

#Introduction

In episode 10 you connected the system to the network: interfaces, routing, DNS, VLAN, and bonding. But a fast network is useless if the data on it can be lost. This episode is about protecting what you already have — keeping the filesystem healthy and building a backup strategy that can genuinely save the day when disaster strikes.

Remember the principle administrators often quote: data that isn't backed up is data that's ready to be lost. This episode combines two worlds: HAMMER2-style filesystem care (hammer2 info, hammer2 status, fsck_hammer2) and classic-modern backup strategies (dump/restore, snapshots, hammer2 send, tar, rsync).

#Filesystem Maintenance

#hammer2 info & hammer2 status

These two commands are the window into filesystem health. hammer2 info shows volume and PFS metadata:

hammer2 info /mnt/data
hammer2 status /mnt/data

hammer2 status shows total size, used space, and bulkfree metadata. Make both part of your monitoring routine — alongside df -h — to detect problems early.

#fsck_hammer2

Filesystem consistency checks are done with fsck_hammer2. This is a deeper diagnostic step than just looking at status:

fsck_hammer2 /dev/da1s1d

Unlike UFS, which needs to be unmounted during fsck, HAMMER2's copy-on-write design is more tolerant. Even so, checks are still best done during low load.

#dump & restore

The classic BSD tools dump/restore back up files by understanding the filesystem structure — not just copying files:

dump -0uf /backup/root.dump /dev/da0s1a
restore -rf /backup/root.dump

For HAMMER2 filesystems, the modern approach is far better — snapshots and hammer2 send (which we'll discuss shortly) work by leveraging HAMMER2's internal structure.

#Backup Strategy

#Snapshots as the Backbone

The best backup strategy on DragonFlyBSD starts with HAMMER2 snapshots. A snapshot is a consistent point-in-time copy created almost instantly:

hammer2 snapshot /mnt/data

Combining snapshots with deduplication lets HAMMER2 keep a long data history without bloating space — each snapshot only stores the blocks that changed since the previous one.

#hammer2 send

hammer2 send transfers data from a snapshot to another location — another host or another disk — using the snapshot model for efficient incremental transfers:

hammer2 send /mnt/data@snap-2026-08-03 /mnt/backup

This feature is still evolving and labeled experimental in 6.4, but it already shows the future direction of HAMMER2 backup: efficient block-level backup instead of copying whole files.

#tar: Portable Backup

tar is the most portable format — its output can be read almost anywhere:

tar -cvzf /backup/data-2026-08-03.tar.gz /mnt/data

For archives that must move between systems of different architectures or OSes, tar is the safest choice. Use the -p flag to preserve permissions.

#rsync: Synchronization

rsync (from pkg) copies data incrementally — only sending the files that changed:

pkg install rsync
rsync -avz --delete /mnt/data/ backup@nas:/backup/data/

-a is archive (recursive + permissions), -z compression, --delete removes files on the target that don't exist on the source. rsync also works over SSH, so backups to remote hosts are secure by default.

#Recovery Order

When disaster strikes, the recovery order determines how much data is saved:

1. Latest snapshot — for files deleted in the last few hours.
2. Off-site rsync/tar copy — for total disk loss.
3. Replication from hammer2 send — for site loss.

Practice recovery regularly. A backup that's never been test-restored isn't a backup — it's just a collection of bytes on a disk.

#Closing

In this episode 11 you learned data care and protection: checking the filesystem with hammer2 info, hammer2 status, and fsck_hammer2, getting to know dump/restore, and building a modern backup strategy with HAMMER2 snapshots, hammer2 send, tar, and rsync.

Key takeaways:

• hammer2 info, hammer2 status, and fsck_hammer2 are the three main filesystem maintenance commands.
• HAMMER2 snapshots are the backup backbone: cheap, fast, and consistent.
• hammer2 send moves snapshots efficiently; still experimental in 6.4.
• tar for portable archives, rsync for incremental synchronization — both work over SSH.
• Apply the 3-2-1 rule and practice recovery regularly.

In the next episode, episode 12, we enter network defense: firewalls: pf & ipfw. You'll build a ruleset in /etc/pf.conf, use tables, configure NAT, manage with pfctl, then compare with ipfw syntax and decide when to choose which.