Secure storage and versioning of configuration backups · OPNsense

A backup file on the firewall’s local disk is not a backup — it is a copy of the configuration that dies with the disk. A backup file in a single off-host folder with no version labels is not much better: it is a copy that cannot be matched to a known-good moment in the firewall’s history. The disciplined storage layer treats backups as versioned, encrypted, and queryable artefacts that an operator can find at 03:00 without scrolling through filenames.

This lesson covers the off-host destination, the versioning scheme, the encryption-at-rest pattern, and the integration with change management that makes backups useful for forensics as well as recovery.

Where the off-host copy should live

Five off-host destinations are common. Each has a place.

Destination	Strengths	Weaknesses
SFTP/SCP to a configuration-management host	Audit trail (SSH keys), append-only filesystem possible, simple to script	Single host becomes single point of failure
Git repository (private)	Full version history, diff between any two snapshots, signed commits	XML is bulky; binary diffs do not compress well; secrets must not be committed in the clear
Object storage (S3, MinIO) with versioning enabled	Cheap, durable, versioned, lifecycle policies	Object storage ACL mistakes have a long history; encryption-at-rest is the operator’s responsibility
Configuration management database (CMDB)	Tied to change tickets, searchable, retention enforced	Often vendor-locked; restores require the CMDB to be available
Encrypted tape or off-line archive	Survives ransomware that reaches the network	Slow to retrieve; not a substitute for online copy

The right primary destination is the one the operator can reach during an incident. The right secondary destination is one that survives a single-site failure. For most teams the combination is git for versioning plus object storage for retention.

Versioning: turning filenames into forensic artefacts

A filename like config-2026-08-15.xml is a date. It is not a version. The disciplined versioning scheme encodes the change context into the filename so the operator can identify the correct snapshot without opening it.

A defensible naming scheme:

config-<hostname>-<yyyymmdd>-<hhmmss>-<change-id-or-tag>.xml

For example:

config-fw-edge-01-20260815-031700-CHG-1043.xml
config-fw-edge-01-20260815-142200-post-incident-3811.xml
config-fw-edge-01-20260816-091500-baseline.xml

The CHG-1043 tag is the change ticket. The post-incident-3811 tag is the incident that triggered the snapshot. The baseline tag is the last known-good configuration before the change. The operator searching the archive for “what did the firewall look like when incident 3811 started” finds the snapshot by tag, not by remembering the date.

The version tag is also what goes into the change-management system. When CHG-1043 closes, the operator attaches the post-change snapshot. When CHG-1043 is rolled back, the operator attaches the pre-change snapshot and labels it pre-CHG-1043. The chain is auditable.

Encrypting backups at rest

The XML contains private keys. Storing it unencrypted in object storage, in a git repository, or in a backup tape is a credential disclosure waiting for an ACL misconfiguration.

Two patterns are common:

Encrypt the entire XML before storage. Use openssl enc -aes-256-gcm -pbkdf2 -salt with a passphrase held in the team’s password manager. The passphrase is in a separate system from the storage.
Use OPNsense’s built-in encrypted backup. The GUI’s encrypted backup uses an operator-supplied passphrase and AES-256-CBC. The same passphrase discipline applies.

The passphrase must be reachable during an incident. Storing it in the same password manager that holds the GUI credentials is a single point of failure if the password manager becomes unreachable. The disciplined pattern is passphrase in the password manager, backup file in object storage, password manager access held by two operators.

Destructiveopenssl encrypt backup— The openssl enc invocation produces an encrypted copy of the XML file. The passphrase is held in the password manager, not in the script. The original unencrypted XML is deleted after the encrypted copy is verified. The .enc extension is a convention; some teams use .xml.aes or .gpg (when using gpg instead of openssl).

$ openssl enc -aes-256-gcm -salt -pbkdf2 -in config-fw-edge-01-20260815-031700.xml -out config-fw-edge-01-20260815-031700.xml.enc

enter AES-256-GCM encryption password:
Verifying - enter AES-256-GCM encryption password:

Illustrative output

Git as a backup store

Git is a defensible backup store for three reasons:

The history is content-addressed. Every commit is identified by its SHA-1. A change to the file changes the SHA-1. The operator can verify the file in front of them is the same file that was committed.
The diff is line-level. A git diff config-2026-08-14.xml config-2026-08-15.xml shows exactly which lines changed between two snapshots. For XML with predictable structure, the diff is almost a changelog.
The signed commit ties the snapshot to the author. A GPG-signed commit on the backup says who took the snapshot and when.

The downside: the XML includes secrets. The git commit must redact before push, or the repository must be configured to filter secrets (with git filter-repo after the fact, or with git-crypt for at-rest encryption). The disciplined pattern is redact before commit, encrypt before push to remote.

Summary

Off-host is not optional. Three copies is the disciplined minimum.
Version tags tie snapshots to change tickets and incidents.
The XML contains private keys. Encryption-at-rest is required.
Git is a defensible backup store if the secrets are redacted before commit.
The passphrase lives in a system separate from the storage.