What to back up before you touch router VPN settings

The export button gives you a file, and the file is the smallest part of being prepared. What actually saves an evening is knowing which pieces that file omits, how you will get back into the router when the tunnel is the thing that broke, and what the restore will not undo. Capture those three things before you open the VPN page. None of the work is difficult, which is exactly why it gets postponed.

What the export actually contains

On most router firmware the export is a settings bundle: interfaces, firewall rules, DHCP reservations, the VPN configuration and often the private keys that go with it. That single file therefore holds secrets, which changes where it may be stored and who may read it.

It is also rarely complete. A profile can reference key material, certificate files or packages that a settings export does not carry, and a restore on a freshly flashed device will bring back the reference without the referenced object. Read the firmware's documentation for the export scope rather than assuming the file is a disk image of your working state.

Encrypt the file if the firmware offers it, and keep it somewhere that is not the router itself. A backup living only on the device it describes disappears at the moment you need it. Treat the export like the credential store it is, because that is what it becomes in the hands of somebody else.

Capture the dependencies around it

A settings file is meaningless without knowing what it belongs to. Record the model, the firmware version, the protocol in use and the role this router plays. Write those facts somewhere that does not require the router to read them back.

Four details decide whether a restore will work:

That last row is the one people skip. If your only route to the router is through the tunnel you are about to reconfigure, you have arranged to lock yourself out at the worst moment.

Write the recovery path down first

Before changing anything, write the steps you will follow if the router becomes unreachable: which cable, which port, which address, which account. Then follow those steps once while the router still works. Verify that the console or management interface responds while everything still works, because discovering a broken console after the failure turns a ten-minute rollback into a site visit.

Include the restore procedure itself in the note, not just the file name. The person reading it may be you, tired, at an inconvenient hour, with no memory of where the file went.

Restore, then verify what came back

A completed restore is not a working network. Check the pieces that silently default: DNS resolver settings, firewall rules that referenced the old interface, and any route that pointed at a tunnel gateway. Open the rules that were edited during the experiment and compare them with what the export contained. A broad allow rule added at midnight and forgotten by morning survives every restore, because it is part of the file you just reloaded.

On an OpenWrt-style device the useful commands print the live tunnel, the routing table and a resolver answer from the router itself:

wg show
ip -4 route
nslookup example.com 192.168.1.1

Then test from an ordinary client rather than from the router. A tunnel that handshakes on the device while clients cannot resolve names is a policy problem, and it will look like a broken VPN to everyone except the person holding the console.

What a restore does not fix

Restoring a key does not revoke anything, and it does not tell you how many copies exist. If the reason for the rollback was a lost device, a shared export or a suspected compromise, the old key is still valid wherever a copy exists, and the restored configuration brings it back into use.

Rotate or revoke the peer through the service's supported process, then update the router and the client that still holds the old material. A backup represents a known working state; it does not represent a known secure one, and the difference matters exactly when a device has gone missing.