After getting my WireGuard server working, I realised something.
If the SSD died tomorrow, or I wanted to reinstall Debian from scratch, would I remember every change I made?
Probably not.
While the installation itself is documented, I wanted a quick way to recover a working WireGuard server without having to generate new keys or reconfigure every client.
Fortunately, WireGuard stores very little state. A proper backup only needs a handful of files.
What actually needs backing up?
Most of the important information lives in your WireGuard project directory.
This contains:
- Docker Compose configuration
- WireGuard configuration
- Server private/public keys
- Client keys (if you chose to keep them)
- Peer definitions
- IP addressing
- Firewall rules contained within the configuration
If these files are preserved, your clients can reconnect immediately after a rebuild because the server keeps the same identity.
In addition to the WireGuard directory itself, I also backed up the system configuration that enables IP forwarding and my Debian network configuration.
For my setup, that meant backing up:
~/wireguard/etc/sysctl.d/99-wireguard.conf/etc/network/interfaces
Creating a simple backup
Rather than remembering every file individually, I created a small backup script.
#!/bin/bash
mkdir -p ~/backups
tar czf ~/backups/wireguard-$(date +%F).tar.gz \
~/wireguard \
/etc/sysctl.d/99-wireguard.conf \
/etc/network/interfaces
Running the script creates a compressed archive similar to:
wireguard-2026-07-19.tar.gz
Everything needed to rebuild the server is now stored in a single archive.
Copying the backup off the server
A backup isn’t much use if it lives on the same disk that could fail.
Since I was working from Windows, I simply copied the archive using SCP.
scp [email protected]:~/backups/wireguard-2026-07-19.tar.gz .
This downloads the archive into the current directory on the Windows machine.
From there it can be copied to another PC, NAS, cloud storage, or wherever you keep your backups.
Why preserving the keys matters
One of the most important files in the backup is the server’s private key.
If you rebuild the server using the same key, every existing client (phone, laptop, tablet, etc.) will reconnect without needing to be reconfigured.
If you generate a brand new server key instead, every client must be updated with the new public key before it can connect again.
Keeping the original keys saves a surprising amount of work.
Documentation is part of the backup
A backup is only half of the recovery process.
The other half is documentation.
A few months from now it’s easy to forget which files were modified, where WireGuard was installed, or which configuration changes were required.
For that reason I’m documenting every service I build.
Eventually I want each service in my homelab to have its own recovery guide.
For example:
- Debian base installation
- Docker installation
- WireGuard recovery
- AdGuard Home recovery
- Nginx Proxy Manager recovery
- Homepage recovery
- Grafana recovery
- Zabbix recovery
If a machine ever fails, I should be able to reinstall Debian and have everything running again simply by following my own documentation.
That’s one of the long-term goals of this homelab: making infrastructure reproducible instead of relying on memory.
What I actually used
This is the exact solution I ended up using.
Backup script
#!/bin/bash
mkdir -p ~/backups
tar czf ~/backups/wireguard-$(date +%F).tar.gz \
~/wireguard \
/etc/sysctl.d/99-wireguard.conf \
/etc/network/interfaces
Copying the backup to Windows
scp [email protected]:~/backups/wireguard-2026-07-19.tar.gz .
Simple, quick, and enough for me to rebuild the WireGuard server without starting from scratch.
I understand that there must be easier and faster ways to do all of the above, but for now this is how I’ll proceed until I come across those methods.