Home Lab Backups That Actually Restore

Who This Is For

Everyone. One of the most important articles on this site.

Think of it like a spare house key hidden with a neighbour. It's completely useless if you've never actually tried it in the lock to check it still works.

What You'll Build

A written backup matrix covering your whole lab, plus one backup you've actually proven restores.

Prerequisites

At least one running service to back up
External or NAS storage

Sync, Snapshot, Backup, Archive, Not the Same Thing

Sync, mirrors changes, including accidental deletions
Snapshot, a fast point-in-time rollback, usually on the same storage
Backup, a separate, restorable copy meant to survive the original failing
Archive, long-term retention, not necessarily quick to restore

The 3-2-1 Rule

Three copies of anything that matters
Two different media types
One copy off-site

What Actually Needs Backup

Application data and databases
Docker Compose files and .env files
Proxmox guest backups
Router/firewall configuration exports
DNS records
Documentation
Password manager export or recovery information

Define Recovery Objectives

What must be restored first if everything goes down at once?
How long can each service realistically be offline?
What amount of data loss is actually acceptable for each service?

Backup Schedule Example

Daily: application data
Weekly: full VM backups
Monthly: a real restore test, not optional

Restore Testing

Actually do each of these at least once, not hypothetically:

Restore a single file
Restore a database
Restore a Docker stack
Restore a Proxmox VM

Documentation Template

$Service:
$Data path:
$Backup job:
$Restore steps:
$Last successful restore test:

Security & Backup Notes

An untested backup is a hope, not a backup, the monthly restore test is the whole point of this article

Troubleshooting

See the Restic Docker Volume Backups article for Docker-specific backup mechanics

Lab Finish Line

A written backup matrix and one tested restore.