Homelab Backup Strategy: Build a 3-2-1 Plan You Can Restore

Disclosure: This guide contains affiliate links.

This page helps homelab operators build a backup plan they can actually restore by separating three layers that should not be mixed together: the live service state, a fast local recovery path, and one encrypted offsite copy.

For most small labs, that means using Proxmox Backup Server where VM or LXC snapshots fit naturally, using a file-level tool such as restic for Docker app data or host directories, and scheduling verification work so the backups do not drift into a false sense of safety.

The unique value of this page is the restore-first framing: instead of treating backups as a checklist item, it maps the common homelab failure modes to the copy type and verification step that prevents a rebuild from turning into guesswork.

Key Takeaways

• RAID is not a backup. Snapshots are not a backup either unless you also have a second copy elsewhere.
• A sane homelab backup design has three layers: primary data, fast local restore, and one encrypted offsite copy.
• Proxmox VMs and LXCs usually fit best in Proxmox Backup Server. Docker app data and Linux host state usually fit best in restic or a similar file-level backup tool.
• The most common backup failure is not software. It is storage running full, jobs silently failing, or nobody testing a restore.
• If you cannot restore one app to a temporary path and start it successfully, your backup strategy is still theoretical.

Why this page needed an update

The older version of this article mixed backups, monitoring, and newsletter blocks into one page. That is messy for readers and bad for search intent. People landing on /homelab-backups/ want a clear backup strategy first, then the monitoring hooks that prove the strategy still works.

So this refresh does three things:

• turns the page into a focused backup guide
• separates workload-specific advice for Proxmox, Docker, and NAS data
• adds a restore-first workflow instead of hand-wavy "set up backups sometime" advice

The mistake I made: backing up machines instead of state

Early on, I backed up entire systems because it felt safer. Full VM exports. Whole-disk copies. Giant archives full of package caches and operating system files I could reinstall in an hour.

That approach looks responsible right up until restore day. Then you realize the parts you actually needed were much smaller and much more specific:

• application data
• database dumps
• Compose files
• reverse proxy configs
• encryption keys
• DNS records
• restore notes

That is why I now split the problem by workload instead of treating the whole homelab like one giant blob.

What a real homelab backup strategy looks like

The 3-2-1 rule is still the simplest framework that survives real failure scenarios:

• 3 copies of your data
• 2 different storage locations or media types
• 1 offsite copy

For a homelab, that usually becomes:

• primary copy on the machine that runs the workload
• local backup copy on a second disk, NAS, or backup server for fast restores
• offsite encrypted copy in object storage, on a remote box, or in another physical location

Here is the model I recommend most often:

That table matters because the backup method should match the shape of the data. A VM image is not the same problem as a Nextcloud data directory or a handful of Compose files.

My recommended three-layer design

Layer 1: primary data stays clean and obvious

Your production data needs a home that makes sense. If you are running Docker, that usually means:

• /srv for persistent app data
• /opt/stack-name for Compose files and overrides
• a predictable place for database dumps
• a predictable place for secrets references, even if the secrets themselves live in a password manager or a dedicated vault

If your data is sprayed across random folders under /root, /home, and mystery bind mounts you forgot about three months ago, your backup job will miss something important.

Layer 2: local restore should be boring and fast

This is the copy you use when a host dies, a bad update corrupts a service, or you fat-finger a delete command.

For Proxmox-heavy labs, I still think a dedicated Proxmox Backup Server is the cleanest choice. Deduplication is good, restore flow is straightforward, and the retention model makes sense for busy VM workloads.

For Docker hosts and plain Linux boxes, I like restic because it is simple, encrypted, scriptable, and happy with local disks, NAS shares, or object storage targets.

Layer 3: offsite is what saves you from the ugly failures

Offsite is where a lot of homelabs quietly fail. People keep two copies on the same shelf, then act surprised when one power event, theft, filesystem corruption, or ransomware incident hits both.

A practical offsite copy can be:

• a remote restic repository on S3-compatible storage
• a second low-power box at another location
• an encrypted repo behind rclone
• a remote PBS sync target for Proxmox-centric environments

If it is not physically separate, it is not really your offsite layer.

What I actually back up in a homelab

I keep this simple.

Tier 1 - painful to lose

Back this up daily, keep retention, and make sure one copy is offsite.

• family photos and documents
• password manager emergency exports if your workflow requires them
• notes, wikis, and documentation
• small business or personal records
• Home Assistant backups
• app databases and uploads

Tier 2 - annoying to lose

Still important, but usually recoverable with some effort.

• Compose files
• .env files and stack configs
• reverse proxy configs
• monitoring dashboards
• VM and LXC definitions
• DNS and DHCP notes

Tier 3 - easy to rebuild

These are nice to have, but they should not dominate your backup budget.

• the base operating system install
• package caches
• container images
• re-downloadable ISO files
• media you intentionally chose not to protect offsite

The reason this tiering works is that it stops you from wasting offsite space on the wrong data. Your offsite copy should protect your life and your rebuild time, not your ability to re-download Ubuntu.

The tools I actually trust

Proxmox Backup Server for Proxmox workloads

If most of your important state lives in Proxmox VMs and LXCs, PBS is the obvious answer. It understands the platform, gives you deduplicated backups, and makes restore workflows much less awkward than juggling random export files.

For Linux host data outside the VM layer, PBS can also back up file archives with proxmox-backup-client. A simple example looks like this:

proxmox-backup-client backup \\n  etc.pxar:/etc \\n  srv.pxar:/srv \\n  opt.pxar:/opt

That is not a replacement for a full VM backup policy. It is the useful extra layer for host configs and app state that you want to restore surgically.

restic for Docker hosts, app data, and offsite copies

For non-Proxmox workloads, restic is still one of the best fits in a homelab because it is boring in the right way.

A minimal setup looks like this:

export RESTIC_REPOSITORY="s3:https://s3.example.com/homelab-backups"\nexport RESTIC_PASSWORD_FILE="/root/.config/restic/password"\nexport AWS_ACCESS_KEY_ID="REDACTED"\nexport AWS_SECRET_ACCESS_KEY="REDACTED"\n\nrestic init\nrestic backup /srv /opt /etc /var/lib/docker/volumes --exclude-caches\nrestic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune\nrestic check --read-data-subset=5%

The command list tells you most of what matters:

• initialize the repo once
• back up the directories with real state
• prune with retention instead of hoarding forever
• verify the repo so corruption is not a surprise later

Monitoring for backup jobs, not just hosts

This is the one monitoring section I still consider mandatory on a backup page.

You do not need a giant observability stack just to know a backup failed. You need a heartbeat, a success signal, and a storage warning.

My minimum alert set is:

• backup job did not start
• backup job started but failed
• backup destination usage crossed a threshold
• repo verification failed

If your backup script can call a heartbeat endpoint or trigger a monitor after success, do it. That simple signal is worth more than a thousand pretty Grafana panels nobody checks.

A backup schedule that works for normal people

This is the cadence I recommend most often:

Daily

• VM or LXC backups for important Proxmox workloads
• app-data backups for anything that changes often
• offsite sync for Tier 1 data

Weekly

• restic or repo integrity check
• review failed jobs and capacity
• prune expired snapshots or archives

Monthly

• restore a random folder
• restore one database dump
• confirm your offsite copy still decrypts cleanly

Quarterly

• do one real service restore
• time how long it takes
• update your restore notes where they were confusing

The restore timing part matters more than people admit. A backup that restores in fifteen minutes is operationally different from one that restores in six hours while you panic and guess.

The restore drill I want you to steal

Pick one service and run this drill in a temporary directory or throwaway VM.

1. Restore its config files.

2. Restore its app data or database dump.

3. Start the service without touching production.

4. Confirm login works and the expected data is present.

5. Write down the exact commands you needed.

If you run Docker, that often means restoring to a temp directory and changing bind mounts in a test Compose file.

If you run Proxmox, that means restoring one VM or LXC to alternate storage or to a non-production VM ID and verifying it boots.

The first time you do this, you will find something stupid. Missing environment files. Wrong permissions. A password file you forgot to back up. That is the whole point.

Common mistakes that make homelab backups useless

Thinking RAID or snapshots solved the whole problem

RAID helps with disk failure. Snapshots help with rollback. Neither one is a full backup strategy by itself.

Backing up media before backing up config

I see this constantly. People obsess over terabytes of Linux ISOs and still have no clean copy of their Compose files, reverse proxy config, database dumps, or restore notes.

That is backward.

Keeping the backup on the same machine only

A second disk in the same box is better than nothing. It is not enough.

Never checking capacity

Most failed homelab backup jobs die because storage filled up or a mount disappeared. Not because the tool was bad.

Having no written restore path

If the only restore knowledge lives in your head, the restore plan disappears the moment you are tired, rushed, or not the one doing the work.

My recommended starting stack for three common homelabs

One mini PC running Docker

• local app data under /srv
• nightly restic backup to a NAS or USB disk
• encrypted offsite restic copy for Tier 1 data
• simple success heartbeat after backup completes

Small Proxmox lab

• PBS for VMs and LXCs
• separate backup of host configs and exported notes
• offsite copy for the irreplaceable app data, docs, and secrets
• quarterly VM restore test

For the deeper Proxmox-specific path, read:

• Proxmox Backup Server Setup for Homelabs: The Workflow I Actually Trust
• Proxmox Backup Strategies: How to Never Lose a VM Again

NAS-first homelab

• snapshots for fast rollback
• second local copy on another box or dedicated backup target
• encrypted offsite copy for critical shares
• monthly random-folder restore test

If your lab leans more toward shared storage and file-level protection, these follow-up guides fit naturally:

• NAS Backup Strategies: How to Use the 3-2-1 Rule Without Turning Your Homelab Into a Full-Time Job
• Restic Backup for Homelabs: The Setup I Use for Linux Servers, Docker Volumes, and Offsite Copies
• Docker Backup Strategies: How to Never Lose Your Containers and Data

Where monitoring and power protection still fit

This page is about backups first, but two adjacent systems still matter.

First, you need enough monitoring to know the backup jobs are still healthy. Failed backups should page you before failed services do.

Second, clean shutdowns protect your filesystem and backup targets from avoidable damage. If your lab still rides out outages with pure optimism, read Proxmox UPS Shutdown with NUT: The Safe Power-Failure Setup I Actually Trust.

My bottom line

If you are starting from scratch, do not overcomplicate this.

Pick one critical service. Back up its data daily. Keep one fast local restore path. Keep one encrypted offsite copy. Test a restore this month, not someday.

That alone will put you ahead of most homelabs that claim to have backups.

If you already have a pile of scripts and snapshots but no restore confidence, slow down and clean up the design. A smaller backup system that you can explain and verify is better than a giant one you only hope works.

Frequently Asked Questions

Affiliate recommendation: Samsung T7 Shield 2TB is a practical portable target for off-host backup copies. Check the Samsung T7 Shield 2TB on Amazon.