Config backup strategy — what to back up, when, and why cadence matters

Every OPNsense firewall has a backup mechanism. The default behaviour is to write a single XML snapshot whenever an operator clicks Save through the GUI, and to keep a small ring of those snapshots on the local filesystem under /conf/backup/. That is a baseline. It is not a strategy. A backup strategy is the policy the operator commits to before an incident forces the decision: how often to back up, what to include, where to send the artefact, how long to keep it, and how to verify it.

This lesson covers the cadence decision, the three types of configuration snapshot OPNsense can produce, and the operational policy that separates a working disaster-recovery plan from a folder of stale XML files no one has ever restored from.

The cadence decision

The right cadence is the cadence that captures every change you cannot afford to redo. Three forces push cadence in different directions:

1. Rate of configuration change. A firewall whose rules change once a quarter needs a different cadence than a firewall whose aliases, certificates, and DHCP reservations change daily.
2. Cost of a lost change. If restoring a three-day-old backup means redoing three days of work, the cadence is wrong.
3. Operational overhead. A backup that fires every minute and pushes 5 MB of XML to a remote store is a backup nobody will inspect. It also fills the disk eventually.

The honest answer for most production firewalls is daily, retained for 30 days, with an extra snapshot before and after every change window. Some teams prefer hourly, retained for 24 hours, plus daily for 30 days. The hourlies catch the typo; the dailies catch the day.

The three OPNsense backup types

OPNsense exposes three distinct snapshot types through System → Configuration → Backups. They are not interchangeable.

The plain XML is the workhorse. It restores cleanly to any OPNsense host running a compatible firmware. The encrypted variant is for the operator who must store backups in a SaaS vault, a tape rotation, or an S3 bucket where the operator does not control the access-control list. The “this firewall” variant is for the rare case where the appliance hardware has failed and the operator is rebuilding on identical hardware with the same plugin set.

The policy that survives operator turnover

A backup strategy is not a backup cron job. The cron job is the easy part. The policy is what the next operator inherits when the original author has left the team.

A defensible policy answers six questions:

1. Where does the backup go? Off-host. A backup on the firewall’s own disk is not a backup; it is a copy of the current configuration that dies with the disk.
2. How is the off-host destination authenticated? API key, SSH key, or stored credential. The credential must be auditable and rotatable.
3. What is the retention? 30 days of dailies is common. 90 days for monthly. Whatever the number, it must be in the policy document.
4. How is the backup verified? A restore drill once per quarter, on isolated hardware, against a known-good snapshot. The drill is logged.
5. Who owns the policy? A named role, not a name. The role inherits the policy when the person rotates.
6. When was the policy last reviewed? A date. Policies without review dates become folklore.

$ configctl backup create plain

Backup created: /conf/backup/config-2026-08-15-0317.xml
Size: 384221 bytes
SHA256: 7f9c1b...

The failure modes that turn backups into theatre

A backup file that has never been restored is a wish. The failure modes are predictable:

• The backup is local only. A disk failure takes both the firewall and the backup.
• The backup is encrypted but the passphrase is in the same password manager as the GUI account. A credential rotation locks out both.
• The backup is captured after the corruption. The cron job runs every 24 hours; the rule that broke things was added at hour 23.
• The backup is captured but never restored. The format changes between major versions and the file no longer loads.
• The backup is captured, archived, and forgotten. The 30-day retention means the latest snapshot is 29 days old when the incident hits.

Each of these is preventable. The mitigation is in the policy: off-host, separate-credential, pre-change, restore-drill, documented retention.

Summary

• The backup strategy is the policy, not the cron job.
• Cadence follows rate of change. Daily retained for 30 days is a defensible default.
• OPNsense offers plain, encrypted, and “this firewall” backup types. Use the right one for the consumer.
• No change without a backup. No backup without a drill.
• The XML contains private keys and shared secrets. Treat it as a credential.