Back Up and Restore an OpenBSD System

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
doas 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 the backup storage and confirm that it is on a separate device. The example assumes /mnt/backup is on another device and / is the filesystem being dumped.

Create a level 0 dump with dump(8) :

doas install -d -m 700 -o root -g wheel /mnt/backup/host
doas sh -c 'umask 077; dump -0auf /mnt/backup/host/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.

Keep the backup directory private and use a new archive filename for each generation. Archives can contain password databases and private keys. 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:

doas sh -c 'umask 077; restore -tf /mnt/backup/host/root.dump > /mnt/backup/host/root.dump.catalog'
  # Read the complete archive directory
doas test -s /mnt/backup/host/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) :

(
    set -o pipefail
    doas dump -0af - / | ssh backup@backup.example.net \
        'umask 077; cat > openbsd-host-root.dump'
)

Run this example in OpenBSD ksh. The subshell enables pipefail so a failure from either dump or SSH makes the pipeline fail. A failed transfer may leave a partial remote file; do not treat it as a completed backup.

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:

doas mount /dev/sd2a /mnt/restore-test &&
    doas sh -c 'cd /mnt/restore-test && restore -rf /mnt/backup/host/root.dump'
  # Restore only if mounting the prepared test filesystem succeeds

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:

doas sh -c 'cd /mnt/selective-restore && restore -if /mnt/backup/host/root.dump'

The interactive add, delete, and extract commands select paths without replacing unrelated live files.

Use Incremental Dumps #

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 the required incrementals with restore -r in their documented order. Keep the restoresymtable file in the destination between passes; remove it after the final incremental restore. Test that entire chain, not only the newest file.

After a full filesystem restore, create a new level 0 dump before resuming incremental backups. Restoring can change inode numbers, so the previous incremental chain cannot serve as the basis for new dumps of the restored filesystem.

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 off the host, protected from deletion through the host’s usual administrator accounts.
  • Retain multiple generations so delayed corruption or accidental deletion does not replace every good copy.
  • Record passphrases, keys, backup locations, and who can perform recovery 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:

  1. how to boot verified installation or recovery media;
  2. how to identify replacement disks without relying on previous device numbers;
  3. how to recreate outer partitioning, disklabels, softraid, and filesystems;
  4. which archives restore each filesystem and in what order;
  5. how to restore /etc/fstab and install platform boot blocks;
  6. 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.

Report a bug