What is the difference between a backup and disaster recovery?

A backup is a copy of data. Disaster recovery is the documented, rehearsed process of turning that copy back into running services. Most homelabs have the first and not the second, which is why a disk failure turns into a lost weekend instead of a lost hour.

How long should a full homelab restore take?

For a single mini PC running Proxmox with a handful of Docker services, a realistic target is two to four hours from dead hardware to tier-one services back up, assuming replacement hardware is on hand. If you have never timed it, you do not have a target, you have a hope.

Do I need a second server for disaster recovery?

No. What you need is backups on separate physical media plus one copy off-site, and a rehearsed restore path. A second server shortens downtime, it does not replace the runbook. Spend the money on a UPS and a second drive before you spend it on redundant compute.

What is the single most common disaster recovery failure?

Discovering at restore time that the backup was incomplete. Usually the volumes were captured but the compose files and the .env secrets were not, so the data exists and nothing knows how to start. Back up the configuration alongside the data.

How often should I test a restore?

Do a granular single-service restore quarterly and a full guest restore twice a year. Automate a monthly checksum verification of the archives themselves if you can. An untested backup is a guess.

Should my recovery runbook live in my self-hosted wiki?

Not only there. If the runbook lives exclusively on the machine that just died, it is not a runbook. Keep a copy on your laptop, in a cloud note, or printed. It is the one document that has to survive the outage it describes.

Homelab Disaster Recovery: How to Get Everything Back When It Breaks

This guide contains affiliate links for hardware I actually run. They cost you nothing extra and help keep the site going.

Everyone in this hobby eventually gets the backup thing right. You set up vzdump, you write a volume script, you push a copy off-site, and you feel finished. You are not finished. Backups are the cheap half of the problem. The expensive half is the afternoon your boot drive dies and you find out that you have forty gigabytes of perfectly good archives and absolutely no idea what order to put them back in. That gap between “I have backups” and “I can restore” is where most homelabs actually lose data.

This guide is the restore half. It assumes you already have something running along the lines of my stack, and that you have worked through backup strategy or at least have Proxmox snapshots and backups scheduled. If you are still setting the foundation up, how to start a homelab comes first. What follows is the runbook, the priorities, and the drill that proves the whole thing is real rather than theoretical.

The Four Failures Worth Planning For

Homelab disasters are boring and repetitive. Plan for these four and you have covered nearly everything that will actually happen to you:

A single service breaks itself. A bad container update, a corrupted database file, a config you edited at midnight. Everything else is fine. You want a surgical restore, not a full rebuild.
A guest dies. A VM or LXC will not boot, or its filesystem is corrupt. The host is healthy.
The host disk fails. The mini PC still powers on, the NVMe does not. Everything is gone at once and you are reinstalling from bare metal.
The site loses power or the hardware dies outright. A brownout during a write, or a dead PSU. Same as the third case, plus a hardware purchase and a wait.

Notice that only two of the four require the heavy path. Most incidents are the first case, which is exactly why granular per-volume backups earn their keep alongside whole-guest archives.

Recovery Tiers: Decide the Order Before You Need It

The single most useful thing you can do before a disaster is decide what comes back first. During an outage you will be tired and you will restore whatever you happen to think of, which is usually the fun service rather than the important one.

Sort every service into three tiers:

Tier	Meaning	Typical services	Target recovery
1	Someone in the house notices within an hour	DNS, reverse proxy, password manager, photo backup ingest	Same day
2	Noticed within a day, real inconvenience	Media server, document management, dashboards, notes	Within a few days
3	Nobody notices for a week	Monitoring history, metrics retention, test containers, labs	Whenever

The tiering matters more than the technology. My tier one is DNS and the reverse proxy, because when Technitium is down nothing else in the house resolves and every other restore gets harder. Password manager is tier one for an obvious reason: half the credentials you need during recovery live in it. If you self-host Vaultwarden, make sure you also have an exported emergency copy somewhere offline, because a password manager you cannot reach during an outage is not helping you.

Write the tiers into a file. Three lines each. That file is the first page of the runbook.

What Goes In the Recovery Kit

The recovery kit is everything you need that must not depend on the homelab being up. Mine is a folder that syncs to my laptop plus one printed page.

Proxmox installer ISO on a USB flash drive that is already written, not one you plan to write when the time comes.
Every docker-compose.yml, in a git repo or a synced folder. Data without configuration is not recoverable in any useful timeframe.
Every .env file. These hold the database passwords, API keys, and admin credentials your stacks need to start. They are also the thing most people forget, because .env is gitignored by default and quietly falls out of the backup set.
The host details in plain text: Proxmox host IP, subnet, gateway, storage names, VMIDs and what each one is. During an outage DNS may be the thing that is broken, so the IP has to be written down.
Backup repository credentials. If your off-site copy is a restic repository, the repository password is the entire ballgame. Lose it and the backups are cryptographically useless. Put it in the kit, and put the kit somewhere physically safe.
The runbook itself, on paper or on a device that is not part of the homelab.

That last point is the one people get wrong. A recovery runbook stored only in your self-hosted wiki is a runbook you cannot read during the exact event it was written for.

Step 1: Recover a Single Docker Service

This is the case you will hit most often, and the one to practice first because it is low risk. Assuming a per-volume backup script like the one in the homelab automation guide, the sequence is stop, replace, start:

# 1. Stop the service so nothing writes while you swap its data
cd /opt/stacks/paperless
docker compose down

# 2. Move the damaged volume aside rather than deleting it
sudo mv /var/lib/docker/volumes/paperless_data \
        /var/lib/docker/volumes/paperless_data.broken

# 3. Restore from the archive
sudo mkdir -p /var/lib/docker/volumes/paperless_data
sudo tar -xzf /mnt/backups/docker-volumes/paperless_data-2026-08-18.tar.gz \
        -C /var/lib/docker/volumes/paperless_data

# 4. Bring it back
docker compose up -d
docker compose logs -f

Two habits make this reliable. Move the broken data aside instead of deleting it, so a failed restore does not become a worse outage. And watch the logs on startup rather than assuming a clean docker compose up -d means success, because a permissions mismatch after a tar extract is the classic silent failure here. If ownership looks wrong, sudo chown -R to the UID the container expects before you start debugging anything more exotic.

Only delete the .broken copy once the service has been running correctly for a day.

Step 2: Recover a Whole VM or LXC

When a guest will not boot, restore the vzdump archive rather than fighting the filesystem. The important trick is to restore to a new VMID so the broken original stays intact for comparison:

# List what you have
ls -lh /mnt/backups/dump/

# Restore a VM to a new ID (original was 101, restoring as 901)
qmrestore /mnt/backups/dump/vzdump-qemu-101-2026_08_18-03_00_02.vma.zst 901 \
  --storage local-lvm

# For an LXC container instead
pct restore 901 /mnt/backups/dump/vzdump-lxc-104-2026_08_18-03_00_02.tar.zst \
  --storage local-lvm

Boot the restored guest with its network disconnected first. Two machines with the same static IP or the same DHCP reservation will fight, and you will spend an hour diagnosing a network problem you created. Verify the data is there, then swap it in properly: shut down the original, move the network config over, start the restored guest.

This is also exactly how you verify a backup without any risk. Restore to a spare VMID, check it, destroy it. That is a five minute job and it is the difference between having archives and having backups.

Step 3: Rebuild the Host from Bare Metal

Boot disk gone, starting over. The order matters here, and it is the part worth rehearsing because it is the one you will never have done before the day you have to do it.

Install Proxmox from the USB you already prepared. Use the same hostname and the same static IP as the old install. Matching them saves you from chasing DNS records and firewall rules later.
Re-add your backup storage. In Datacenter, Storage, Add, point at the external drive or NAS share holding the dumps. Nothing else can happen until Proxmox can see the archives.
Restore tier one first, following your own tier list. DNS and reverse proxy before anything else, because the rest of the restore is far easier when name resolution works again.
Restore tier two, one guest at a time, verifying each before moving on.
Re-apply host configuration: storage mounts, the backup schedule itself, any cron jobs that lived on the host rather than inside a guest. This is the step people forget, and the symptom is a homelab that comes back up and then silently stops backing itself up.
Re-point monitoring. Confirm your Uptime Kuma checks and ntfy alerts are firing again, including the dead man’s switch pings on the backup jobs.

Step five and step six are the ones that turn a successful restore into a fragile one. A rebuilt homelab with no working backup schedule is a homelab that is one failure away from a real loss, and it will look completely healthy while it waits.

Step 4: Solve the Network Chicken and Egg

Here is the trap: your DNS runs in a container, your services are reachable through a reverse proxy, and both of those are on the host that just died. Now you need to reach the Proxmox web UI to start restoring, and nothing resolves.

The fixes are simple and have to be in place beforehand:

Know the host IP by heart or have it in the printed kit. https://192.168.1.x:8006 works with no DNS at all.
Keep a second DNS resolver configured on your router, ideally a public one, so the household internet still works while your resolver is down. This alone prevents the family from noticing half your outages.
If you use Tailscale, remember that its MagicDNS does not depend on your local resolver, which makes it a genuinely useful backdoor into a broken network.
Do not put the only copy of your reverse proxy configuration behind the reverse proxy. Back up the Nginx Proxy Manager data volume with everything else.

Step 5: Run a Real Drill Twice a Year

A restore you have never performed is a plan, not a capability. Twice a year, block out an afternoon and do this properly:

Pick a real backup, not a fresh one you just made.
Restore a tier-one guest to a spare VMID and boot it isolated.
Verify actual content, not just that it booted. Open the app, check that yesterday’s data is present.
Time it. Write the number down.
Note every single step where you had to improvise or look something up.

That last item is the point of the whole exercise. Every improvisation is a bug in your runbook. Fix the document while it is fresh. On my own setup the drill is what surfaced that a couple of .env files had never been in the backup set, which is a five minute fix on a Saturday and a ruined weekend if you find it during a real failure.

If you want the automated version of this, have a monthly job restore a small sample from the off-site repository and checksum it, then ping a dead man’s switch on success. That gives you a continuously proven backup rather than a twice-yearly opinion.

The Hardware That Actually Buys You Time

Most of disaster recovery is process, but two pieces of cheap hardware genuinely reduce how often you need it.

A UPS is the highest-value purchase in the entire homelab for the money. It is not there to keep you running through a long outage. It is there to prevent the write-in-progress corruption that turns a two second brownout into a corrupt database and a restore. A basic line interactive unit is enough for a mini PC and a switch, and the UPS roundup covers what is worth buying. If you want to go straight to a shortlist, a 1500VA line interactive UPS covers a small stack with room to spare.

A second physical drive for backups matters more than a bigger one. Backups on the same disk as your VMs protect against mistakes and nothing else. A portable external SSD plugged into the mini PC is enough to get the archives off the boot device, and the storage options rundown covers the tiers above that. Pair it with one off-site copy and you have the meaningful version of 3-2-1 without buying a NAS.

The Honest Assessment

You will not build a perfect disaster recovery setup, and you do not need one. What you need is the tier list, the recovery kit including the .env files, and one rehearsed restore per year that you actually timed. That is maybe three hours of work total, and it converts the worst day of your homelab’s life from an open-ended crisis into a known procedure with a known duration.

The reason this is worth doing on a budget homelab specifically is that nobody else is going to do it for you. There is no support contract and no replication cluster. The runbook is the redundancy. Write it, print it, and run the drill.