Most homelab backups fail not because the backup tool is bad, but because the backup plan was never tested. A backup that has not been restored is not a backup; it is an archive of hope. This guide covers a realistic backup strategy for homelab servers, from selecting what to back up to automating rotations and testing restores without breaking your production setup.
What to Back Up
Start with data that cannot be rebuilt easily. For most homelabs, that means:
- Virtual machine disks and configuration from Proxmox
- Docker volumes and compose files
- Configuration files for critical services
- Databases and application state
- Important media, documents, and photos
You do not need to back up every container image or package list. Those can be rebuilt from code and Dockerfiles. Focus on stateful data.
The 3-2-1 Rule
The simplest reliable strategy is three copies of your data, on two media types, with one copy offsite. In a homelab context, that might mean:
- Primary copy on your server’s main disk
- Local backup on an external USB drive or NAS
- Cloud or remote backup on Backblaze B2, Wasabi, or another object storage provider
Two media types matter because disks fail together more often than we admit. A local backup on the same disk type as the primary is not a second medium.
Tools for Homelab Backup
Proxmox has built-in backup jobs for VMs and containers. Use them. They run while VMs are running, schedule automatically, and store backups in a directory you choose. Pair this with vzdump for manual exports.
For Docker volumes, use scripts that tar the contents of named volumes and copy them to your backup target. The command is straightforward and works well with cron.
For configuration files, use Git. Version control your docker-compose files, nginx configurations, and scripts. If a service breaks, you can redeploy from the repository instead of troubleshooting from memory.
For object storage, use rclone to sync backup directories to Backblaze B2 or Wasabi. rclone encrypts data before upload and verifies transfers.
Automation
Manual backups do not survive busy weeks. Automate with cron on a dedicated backup machine or a Raspberry Pi. Schedule full backups weekly and incremental or differential backups daily.
A simple cron job might run a script that stops a database container briefly, exports the database, tars the named volume, and copies the archive to a NAS.
Keep logs. Every backup job should write a timestamped log entry. If a job fails, you want to know immediately, not three months later when you need the data.
Retention and Rotation
Keep multiple backup generations. A common rotation is:
- Daily backups for seven days
- Weekly backups for four weeks
- Monthly backups for six months
Delete old backups automatically with a script or a tool like restic, which handles retention policies natively.
Restore Testing
Testing is the step everyone skips and the step that matters most. Every quarter, pick a backup and restore it to a test environment. Verify the data is complete, the application starts, and the service behaves as expected.
Test restores do not need to use the original server. Use a spare machine, a Proxmox test VM, or a temporary directory on your workstation. The goal is to prove the backup works, not to practice production recovery.
Ransomware Considerations
If a homelab server is infected with ransomware, local backups on the same network can be encrypted too. Object storage with versioning or a backup target that is not always mounted reduces this risk.
Do not keep your backup drive permanently connected. Mount it during the backup window, then unmount it. An offline backup cannot be touched by ransomware running on the main server.
Final Thoughts
Backup strategy is boring until you need it. The difference between a minor inconvenience and a major loss is usually the presence of a tested restore. Automate backups, keep them offsite, rotate them regularly, and test restores every quarter.
You may also want to read our guides on backup restore testing, Proxmox Backup Server, and self-hosted monitoring stack.