VPN Server Backup: Decide What Must Be Restorable

Copying a configuration file is not a backup, and a backup nobody can restore is not a plan. The archive has to contain the identity of the service, the policy around it and the state that says which devices are still allowed. It also has to be protected, because in most deployments the archive grants exactly what the VPN grants. Deciding what must be restorable comes first; the file list follows from that decision.

Start From the Rebuild Target

Write down what a rebuilt server must do before listing a single file: terminate the same tunnels, present the same identity, and refuse the devices that are currently revoked. That sentence rules out most naive copies, because a configuration directory rarely contains the revocation list or the external identity dependency. It also exposes the parts living outside the host, such as DNS records, cloud firewall rules and the directory the gateway authenticates against. A plan that ignores them produces a restored server that looks healthy and admits nobody.

Group the material into three buckets: identity, configuration and state. Identity is the keys, the certificates and the authority that signs them. Configuration is the daemon settings, pools, routes and firewall policy, while state is the set of peers, accounts and revocations that changes every day.

Identity Is the Part You Cannot Regenerate

Private keys cannot be recreated from memory, and the certificates that depend on them expire on a schedule you inherit rather than choose. Back up the server key, the client provisioning material and the certificate authority, then note which of those are supposed to stay offline. An authority key that lives only on the running gateway is one compromise away from a full identity reset for every client. Record what is deliberately stored elsewhere so nobody duplicates it into a lower-protection archive.

Revocation deserves its own line in the plan. Restoring yesterday's configuration can reinstate an identity you removed today, which turns a recovery into a security incident. Keep the current revocation state somewhere independent of the snapshot you would roll back to, and check it after any restore.

Snapshot the State at One Moment

A copy taken while the service is writing produces an inconsistent inventory, and inconsistent identity data is worse than an older clean copy. Use the supported export path for each store, then record the snapshot time, because every later question about the restore depends on it.

wg showconf wg0 > /srv/backup/wg0.runtime.conf
sqlite3 /var/lib/vpn/admin.db ".backup '/srv/backup/admin.db'"
cp -a /etc/wireguard /srv/backup/etc-wireguard
sha256sum /srv/backup/*.conf > /srv/backup/MANIFEST

The first command prints the running interface back as configuration, which is the fastest way to capture peers that were added by hand rather than by a management tool; the wg(8) manual documents it. The sqlite line is the pattern for a management database: the backup command produces a consistent copy while the writer keeps running. The directory copy preserves permissions, which matters because those key files are readable only by root. The manifest is what lets you tell a complete archive from a truncated one.

Make the Restore Possible, Then Try It

Encrypt the archive and keep the recovery key somewhere other than the machine it came from. A backup whose passphrase exists only on the failed server is a backup nobody will open. Restrict retrieval to the people who could already administer the gateway, and log each retrieval. Test the restore on an isolated network, because a cloned identity brought up beside production creates two servers answering for the same peer key.

Document the exclusions as carefully as the contents. Cloud firewall rules, DNS records and an external directory may each need their own recovery step. A successful file copy is not evidence that the service returns; the only evidence that counts is a rebuilt endpoint passing the same acceptance test as the original.