Learn OpenBSD - Data Management & Backup

#Introduction

In episode 10 you secured services with TLS and automatic certificates. But all that configuration, those certificates, and that data are only worth something if they can be restored. This episode covers the side administrators often forget: data management and backup.

The OpenBSD philosophy applies here too: use proven built-in tools, understand what you're doing, and never trust a backup that hasn't been restore-tested. Backup isn't an "if you have time" activity — it's insurance whose price becomes visible precisely when data is lost.

#Filesystem Maintenance: fsck in Context

Episode 7 introduced fsck for filesystem checking. In the context of data management, fsck is the first step before backing up: don't back up a damaged filesystem. The correct pattern:

umount /dev/sd0d
fsck -y /dev/sd0d
mount /dev/sd0d

Also check usage and inodes so there are no surprises during backup:

df -h
df -i

df -i shows inode usage. Running out of inodes can happen without the disk being full — a condition that makes applications behave strangely.

#dump and restore: Reliable Built-in Tools

dump backs up a filesystem at a supported level (0 = full, 1-9 = incremental). Its advantages: it works on the raw device, preserves metadata, and supports incremental backups:

dump -0au -f /backup/root.dump /dev/sd0a
dump -1au -f /backup/root.inc.dump /dev/sd0a

• -0 level 0 (full), -1 the first incremental level.
• -a detects media capacity, -u records history in /etc/dumpdates.

Recovery is done with restore:

restore -rf /backup/root.dump
restore -tf /backup/root.dump

-r performs a full restore, -t lists the contents without extracting. Always check the contents list first.

#FFS Snapshots: Backup Without Downtime

FFS2 supports snapshots: a consistent image of a filesystem without stopping services. Take a snapshot then dump from it:

mount -u -o snapshot=/var/snap/root.snap /dev/sd0a
dump -0af /backup/root.snap.dump /var/snap/root.snap
mount -u -o snapshot= /dev/sd0a

The snapshot is mounted as a file in the /var/snap directory, then dumped like a regular filesystem, then released. This is the correct pattern for production servers that can't stop.

#tar and cpio: File-Based Backups

For backing up specific directories (not a whole filesystem), tar and cpio are the choices:

tar -czf /backup/etc.tgz -C / /etc
tar -tzf /backup/etc.tgz | head

cpio is useful when the file list is produced by another command:

find /var/www -type f | cpio -o > /backup/www.cpio

Note that tar and cpio work at the file level, not the filesystem level — fast and flexible, but they must be run on a live system or from read-only mounted media to be consistent.

#rsync: Synchronization and Remote Backup

rsync is the most popular third-party package for synchronization. Install it first:

pkg_add rsync

Then synchronize a directory to a backup server:

rsync -aAXv /var/www/ backup:/backup/www/
rsync -avz --delete /var/www/ backup:/backup/www/

The -a (archive), -X (preserve xattrs), -z (compression), and --delete options make rsync mirror the source to the destination. For rsync over SSH, add -e ssh — taking advantage of the SSH you'll harden in episode 14.

#Base System Backup Strategy

The OpenBSD base system rarely changes except during upgrades, but its configuration files absolutely must be backed up. The minimum list that should always be in a backup:

tar -czf /backup/base-config.tgz /etc /root /var/cron
ls -la /backup

Also consider recording the package list so you can reinstall quickly:

pkg_info -Q | awk '{print $1}' > /backup/packages.txt

This packages.txt file is a "manifest" that enables fast recovery: install clean OpenBSD, run pkg_add $(cat packages.txt), and your system is back.

#Building a Backup Schedule

A sensible combination for a production server:

• Daily: rsync application data to another machine.
• Weekly: level 0 dumps for important filesystems, via /etc/weekly.local.
• Monthly: FFS snapshots + dumps, stored on separate media.
• Continuous: the package and config manifest for fast recovery.

All of these schedules can be run by OpenBSD's built-in cron without extra tools.

#Closing

In episode 11 you managed and secured OpenBSD data: maintaining filesystems with fsck before backup, using dump/restore with FFS snapshots for consistency, archiving with tar and cpio, synchronizing with rsync, and arranging a restorable base system backup strategy.

Key takeaways:

• Don't back up a damaged filesystem; check it with fsck first.
• dump works at the filesystem level, tar/cpio at the file level, rsync for synchronization.
• FFS2 snapshots enable consistent backups without downtime.
• A backup that has never been restore-tested is just hope.

In the next episode, episode 12, we enter the heart of OpenBSD's network security: pf firewall fundamentals — understanding /etc/pf.conf, the ruleset concept, block and pass, service rules, logging via pflog, and the habit of validating with pfctl.