How to Restore a VPN Server Without Duplicating Identities

You restored the backup, the service started, and a client connected on the first try. That success is the trap. A restore returns the files the server had at snapshot time, not the access state that has changed since, and if the old endpoint is still reachable you now have two machines answering to one identity. The fix is not a better backup; it is deciding what the restored host is allowed to be before it answers a single handshake.

A backup returns files, not authority

The snapshot holds the server configuration, the private keys, the certificate authority, the peer list and the firewall rules as they stood when the backup ran. It cannot hold what changed afterwards: the device you revoked, the key you reissued, the peer you removed when a laptop was sold, the subnet you moved. Restoring rewinds the files to that moment. It does not rewind the decisions people made since.

That gap is where the damage comes from. A stolen laptop revoked two weeks after the backup presents a certificate that still verifies against the older CRL inside the restored tree, and the server accepts a device you retired. WireGuard is blunter: a peer is authorized by being listed, so a peer deleted after the snapshot is simply present again. Nobody re-approved that access. The old file did.

Server identity and client identity fail in different ways

On WireGuard the server's identity is the private key in wg0.conf, so copying that file to a second reachable host creates two servers with the same identity and no knowledge of each other. Each keeps its own peer list. Remove a peer on the new host and the old one still accepts it; check wg show on one and you see half the truth. Clients do not fail over on their own either: a profile carries one Endpoint, so a device keeps talking to whichever address it was configured with, which may be the host you meant to retire.

OpenVPN duplicates at the same layer with a server certificate, its private key and the tls-auth or tls-crypt static key. Copy all three and a client cannot tell the instances apart; if both are reachable, a reconnect may land on either, and each log file tells a partial story. The certificate authority is the deeper copy. A restored easy-rsa tree is a second source of truth that can issue a valid certificate for any name you give it.

Clients get duplicated too, usually during the migration itself. Copying a profile to a spare device "just to test" produces a second device with the same key and common name. With duplicate-cn both sessions can stay up at once, and a static address assignment in ccd or ifconfig-pool-persist can collide with the original device. That is two machines wearing one identity, and nothing in the server config distinguishes them.

Pick one of three states for the old endpoint

A restore is only safe once the old endpoint's fate is decided. Retire it: the old service must stop accepting the VPN port before the new host starts, and if you cannot reach the machine, block that port at the network edge for everything except your administrative source. Repair the same host: reusing the identity is fine because one machine holds it, but destroy the disk copy or VM snapshot of the old key afterwards so it cannot return. Build an availability pair: two hosts need distinct host identities plus one shared endpoint, such as a floating address, a load balancer, or DNS you can move. Copying the private key is not a failover design; it is two servers claiming one name.

Confirm which state you are actually in before touching clients. The old host answering on the VPN port is the one that will accept the revoked device, even if DNS has moved. Check listeners and the public key:

ss -lunp | grep -E ':51820|:1194'
wg show wg0
wg pubkey < /etc/wireguard/server.key

Reconcile peers, revocations and addresses first

List what the restore claims against what is currently authorized. On WireGuard, wg show wg0 gives each peer's key, endpoint, latest handshake and transfer counters, which is enough to spot a device you no longer own. Remove it live with wg set wg0 peer <key> remove, then edit the config as well, or the peer returns at the next start. wg show wg0 allowed-ips exposes the second problem: two peers on one address, or an address you already reassigned.

On OpenVPN, the revocation list is a file with a date, and a restore can bring back an old one. Check it before clients connect:

openssl crl -in /etc/openvpn/crl.pem -noout -lastupdate -nextupdate
grep -E 'crl-verify|reneg-sec' /etc/openvpn/server.conf

If the last update predates the revocation, the server is still honoring a certificate you revoked. OpenVPN 2.4 and later re-read the CRL file for each new connection, so replacing the file stops new sessions, but established tunnels persist until renegotiation; the default reneg-sec is 3600 seconds, and lowering it or restarting the service is what gives you the change now. Older builds may not pick up the file as reliably, so restart when you cannot confirm the version's behavior. The wg(8) manual covers the peer removal and allowed-ips syntax used above.

Also clear static assignments for devices that no longer exist. Reusing a retired device's address for a new one while the old profile is still installed creates exactly the duplicate you are trying to avoid.

Verify with a client you revoked

Run the checks in order, from a network outside the tunnel. First an authorized device connects, resolves DNS through the pushed resolver and reaches a private resource. Then the revoked device must fail, using its existing profile rather than a fresh one. Then try the old endpoint from outside: if the VPN port still completes a handshake, the old host is live and the duplication is real, not theoretical.

Reboot the restored host and repeat the authorized and revoked checks, because that is when the config file wins over whatever you changed at runtime. Compare the host's public key or certificate fingerprint with the one the retired machine used. Matching fingerprints on two live machines mean the restore cloned the identity; matching fingerprints on one machine are fine. Record the restored versions, key fingerprints and the revoked serial or peer key, then take the next backup after this reconciliation, so it represents the service as it now is. The working test is not that a client connects. It is that the client you removed stays out while the old endpoint stays closed.