Synopsis #
A usable backup has an independent copy, a known retention policy, integrity checks, and a tested restore procedure. OpenBSD provides dump(8)
and restore(8)
for FFS filesystems, plus the /altroot facility for a local root-filesystem copy.
RAID, disk encryption, and /altroot solve different problems. RAID preserves availability after some disk failures. Encryption protects confidentiality. /altroot provides a nearby root copy. None replaces an offline or off-host backup.
Inventory the Restore Scope #
Record filesystems, disklabel UIDs, mount options, softraid volumes, boot method, and installed packages:
$ mount
# Record mounted filesystems
$ df -h
# Record capacity requirements
# disklabel sd0
# Record the boot disk layout; repeat for every disk
$ pkg_info -mz
# Record manually installed packages
Store this inventory with the backup, not only on the system being backed up.
For databases, mail stores, virtual machines, and other stateful applications, define a consistent backup method before copying files. Stop the service, use its supported export or checkpoint mechanism, or otherwise establish application consistency.
Create a Full FFS Dump #
Mount independent backup storage and identify it positively. The example assumes /mnt/backup is on another device and / is the filesystem being dumped.
Create a level 0 dump with dump(8) :
# dump -0auf /mnt/backup/root.dump /
The -0 option creates a full dump, -a permits the output to extend to the medium’s end, -u records the completed dump in /etc/dumpdates, and -f selects the output file.
Run one dump per FFS filesystem. Use names that identify the host, filesystem, level, and date. A mounted filesystem can change while dump reads it; use a maintenance window or an appropriate application-consistency method when those changes matter.
Check the archive catalog immediately:
# restore -tf /mnt/backup/root.dump > /tmp/root.dump.catalog
# Read the complete archive directory
# test -s /tmp/root.dump.catalog
# Confirm that a nonempty catalog was produced
An archive that can be listed has passed only a basic readability check. It has not yet passed a restore test.
Copy a Dump Off Host #
An off-host copy protects against local disk failure, theft, operator error, and damage to the machine. One simple transport streams the dump through ssh(1) :
# dump -0af - / | ssh backup@backup.example.net \
'umask 077; cat > openbsd-host-root.dump'
The remote account should be restricted to backup storage and should not permit the protected host to erase all retained generations. Verify the remote file size and catalog from a separate recovery environment.
Test a Restore #
Restore into an empty filesystem that is not the active system. Confirm the destination before extracting:
# mount /dev/sd2a /mnt/restore-test
# Mount the prepared, empty test filesystem
# cd /mnt/restore-test
# Make the test filesystem the extraction target
# restore -rf /mnt/backup/root.dump
# Restore the complete level 0 archive
Inspect ownership, modes, links, device nodes, and representative application data. Boot testing requires a correctly partitioned disk, all required filesystem restores, /etc/fstab, and platform-appropriate boot blocks. A successful file extraction alone does not prove bare-metal recovery.
For a small selective restore, use interactive mode in an empty directory:
# cd /mnt/selective-restore
# restore -if /mnt/backup/root.dump
The interactive add, delete, and extract commands select paths without replacing unrelated live files.
Use Incremental Dumps Deliberately #
Incremental levels reduce backup volume but increase restore complexity. Every incremental depends on the most recent lower-level dump. Document the exact restore order and retain complete chains.
A conservative schedule uses periodic level 0 dumps plus a limited number of lower-volume incrementals. Do not delete the base dump while any retained incremental depends on it.
During recovery, restore the level 0 archive first, then apply incrementals in their documented order. Test that entire chain, not only the newest file.
Configure /altroot
#
OpenBSD’s daily(8) scripts can duplicate the root partition to a designated partition. The destination must be at least as large as the root partition and should be on a separate bootable disk.
Create /altroot, identify the destination by disklabel UID, and add an entry to fstab(5)
:
bfb4775bb8397569.a /altroot ffs xx 0 0
The DUID is an example. Use the actual destination DUID and partition. Enable the daily copy in /etc/daily.local:
ROOTBACKUP=1
The daily script performs a disk-image copy of the root partition. The destination must not be mounted for ordinary use. Review the next daily report and verify the copy from a controlled recovery boot.
/altroot is updated automatically and can reproduce unwanted changes or corruption. It is attached to the same host and does not retain multiple generations. Keep independent backups.
Protect and Retain Backups #
- Encrypt backup media when its physical security is not sufficient.
- Keep at least one copy outside the host and its ordinary administrative trust path.
- Retain multiple generations so delayed corruption or accidental deletion does not replace every good copy.
- Record passphrases, keys, media locations, and recovery authority separately.
- Monitor backup completion, output size, catalog checks, retention, and restore-test age.
- Remove or rotate backup access when administrators or systems change roles.
Recovery Runbook #
A bare-metal runbook should state:
- how to boot verified installation or recovery media;
- how to identify replacement disks without relying on previous device numbers;
- how to recreate outer partitioning, disklabels, softraid, and filesystems;
- which archives restore each filesystem and in what order;
- how to restore
/etc/fstaband install platform boot blocks; - how to verify services before reconnecting the system to production networks.
Recover an OpenBSD System That Does Not Boot covers the boot path. Configure softraid RAID1 covers storage redundancy, which must be backed up independently.