RunBook AcademyOPNsense

← All checklists in OPNsense

Quarterlybackup-dr

Backup and Disaster Recovery

17 items ·10 critical ·7 warn ·0 info

The OPNsense firewall holds the rule set, the NAT, the VPN tunnels, the certificates, and the operator’s policy in one XML export. A tested restore from that export is the difference between a 30-minute recovery and a week of forensic rebuild. This checklist enforces the discipline: scheduled backups, encrypted off-site destination, a quarterly restore test, documented RPO / RTO, and a DR runbook that someone other than the author can follow.

When to use

Use this checklist quarterly on every production OPNsense firewall, after any change to the backup pipeline, after any incident where backups were missing or failed, and as part of an annual DR exercise. It is the right checklist to share with the auditor when they ask “show me your DR plan.”

How to use

Walk the list, schedule a restore test in the lab for the same week, exercise the DR runbook, capture the timings and findings, and file them with the operator’s continuity record. Anything with severity critical must be satisfied before the quarter closes.

Critical10 items

Configuration backups are scheduled (System > Cron) and target a remote destination: SSH / SFTP, Nextcloud, API push, or a network share.
```
System > Configuration > Backups; System > Cron.
```
Backup retention policy is explicit and the destination enforces it (off-box lifecycle policy).
Backups are encrypted at rest, both on the firewall (password-protected XML export) and on the destination.
A restore test has been performed in the last quarter: backup downloaded, restored to a lab or staging firewall, and validated.
Restored configuration is verified against the original: interfaces, rules, aliases, NAT, VPN, certificates, users, plugins.
RPO (recovery point objective) and RTO (recovery time objective) are documented and aligned with the operator DR strategy.
A DR runbook exists: step-by-step instructions to rebuild an OPNsense firewall from scratch using the most recent backup.
The DR runbook has been exercised in the last 12 months; the exercise is documented with timings and findings.
Off-site / off-region backup destination: backups leave the operator primary site to survive site loss.
Meta-monitoring rule fires when no backup has succeeded in the last 24 hours (or per the schedule).

Warning7 items

Plugin configurations (Suricata, WireGuard, IPsec, Netdata) are part of the backup; they live inside the same XML export.
Custom rules (Suricata), custom certificate store, and SSH keys for admin are included in the backup scope.
Configuration is also stored in version control (Git) so that changes are diff-able and rollback to any prior version is possible.
```
git init; git add config.xml; commit each change with the change record ID.
```
HA pairs: backup captures the XML exports from both nodes; restore test exercises sync restoration on both nodes.
Backup destination credentials are stored in the operator vault and rotated on the operator credential schedule.
A separate, documented "fallback operator" can rebuild the firewall from the runbook without the primary author.
Firmware version used for the rebuild is reproducible: the operator stores the ISO/IMG alongside the backup or in the runbook.