A Proxmox backup strategy works in production not because it captures everything, but because the operator has restored from it before the disaster happened. Many operators have backups they cannot actually restore.
An untested backup is a hope, not a backup.
This guide covers what backup actually means in Proxmox, how PBS and vzdump differ, where backups should live, what 3-2-1 looks like in homelab reality, how to validate restores before you need them, and the restore-time problem that turns “working backups” into multi-day disasters.
Quick answer
Best Proxmox backup strategy for most homelabs:
PBS + external drive + tested monthly restore.
Avoid relying on:
- Snapshots alone
- Single backup destination
- Untested backup schedules
TL;DR
- Snapshots are not backups. Backups must live on separate storage.
- PBS gives deduplication, integrity verification, incremental forever
- vzdump is the built-in fallback for simple environments
- 3-2-1 rule: 3 copies, 2 media types, 1 offsite
- Test restore monthly, not annually. Backups age silently.
- “Backup successful” is not “restore tested”
Why backup is the topic operators avoid until they can’t
Backup is the topic homelab operators schedule for “next weekend” until disaster makes it urgent.
The pattern: VMs are running, services work, dashboards show green. Backup configuration looks tedious — setting up PBS, configuring schedules, allocating external storage, documenting restore procedures. None of it feels urgent.
Then something breaks. Suddenly it’s all urgent at once, and the cost of skipping prep becomes obvious.
RackNotes principle
Backup quality is measured at restore time, not backup time. The backup dashboard reporting “successful” tells you the job ran. It does not tell you whether the data will come back when you need it.
Most backup failures happen during restore, not backup creation. The rest of this article reflects that reality.
What “backup” actually means in Proxmox
Three different mechanisms get called “backup” in Proxmox conversations. They protect against different failures.
Snapshots capture filesystem state at a point in time. The snapshot lives on the same storage as the original VM. Storage failure destroys both. Snapshots are useful for rollback before a software change, not for protecting against storage failure.
Backups copy data to separate storage at a point in time. The backup is independent of the source. Storage failure on the source doesn’t affect the backup. Backups are what most operators mean when they say “backup.”
Replication continuously copies data to another storage system. The destination tracks current state closely. But replication also copies errors, corruption, and accidental deletions. A rm -rf propagates to the replica in seconds.
| Mechanism | Protects against | Doesn’t protect against |
|---|---|---|
| Snapshot | Software changes, configuration mistakes | Storage failure, fire, theft, ransomware |
| Backup | Source failure, deletion, corruption | Time gap since last backup |
| Replication | Source host failure | Coordinated failures, source corruption |
This article focuses on backups. Snapshots and replication get covered in the storage architecture guide. Production environments use all three. Typical hobby setups start with backups only (correct minimum) and add the others as needs grow.
The three things you’re protecting against
A useful backup strategy starts with naming the failures it must survive. Different failures require different mechanisms.
Hardware failure. Disk dies, host crashes, controller fails. The data on that hardware is gone. Backup protects this by living on different hardware.
Data corruption. Software bug writes garbage to a VM disk. Database transaction commits inconsistent state. ZFS scrub finds checksum errors. The data on the source is wrong, not missing. Backup protects this by preserving a point-in-time before corruption — which requires backups that capture multiple historical points, not just the latest.
Ransomware and adversarial deletion. Attacker (or compromised account, or angry employee) deliberately destroys data including backups. The source is wiped. Network-accessible backups are wiped. This requires backup storage that cannot be reached from the systems being attacked — air-gapped, immutable, or offline media.
Many homelab backup strategies protect against the first two and ignore the third. That’s a defensible choice for personal labs. For anything touching real-world data — family photos, business records, financial documents — the third failure mode matters more than the first two combined.
Proxmox Backup Server (PBS) — what it is and what it’s not
PBS is a dedicated backup target server. It runs on its own host (physical or VM) and provides deduplication, integrity verification, incremental-forever backup chains, and a restore interface.
What PBS gives you:
- Deduplication — only changed blocks stored, dramatically reducing storage requirements
- Incremental forever — no monthly full backups, no growing backup chains
- Integrity verification — periodic checksum validation catches corruption before restore
- Encryption — client-side encryption protects backup contents from PBS host compromise
- Granular restore — individual files from VM backups without restoring the whole VM
- Retention policies — keep daily for week, weekly for month, monthly for year, automatically
What PBS is not:
A single-host solution. PBS runs on its own host. Putting PBS on the same Proxmox node as the VMs it backs up loses most of its protection value.
A magic fix for bad backup hygiene. PBS still requires schedule discipline, monitoring, and restore testing.
Free of resource cost. PBS uses RAM proportional to dataset size (covered in our RAM sizing guide), plus CPU for compression and dedup operations.
A replacement for offsite storage. PBS in the same building as your Proxmox cluster doesn’t protect against fire, theft, or local disasters.
Failure scenario
Operator stores PBS datastore on the same ZFS pool as production VMs. Pool corruption destroys both production and backup simultaneously. The “backup” was storage duplication, not disaster recovery.
When PBS is overkill: single-host setups with 2-3 VMs, lab environments that get destroyed regularly, test setups where backup is “nice to have,” or environments where the second backup tier will never get set up anyway.
For small lab environments serious enough to need backup but small enough that PBS feels like overhead, vzdump to external storage is genuinely fine.
vzdump — the built-in backup tool
vzdump is Proxmox’s native backup tool. It creates compressed archive files (.vma for VMs, .tar for containers) and stores them in any configured backup storage location.
What vzdump gives you:
- Works out of the box, no separate server needed
- Multiple backup modes (snapshot, suspend, stop)
- Compression options (none, lzo, gzip, zstd)
- Works to any storage type Proxmox understands (directory, NFS, CIFS, removable)
- Email notifications on success/failure
- Backup retention by count (keep last N backups)
What vzdump lacks:
- Deduplication — every backup is a full backup. Disk usage grows linearly.
- Incremental backups — limited support, mostly full backups in practice
- Integrity verification beyond basic checksums
- Granular restore — restore the whole VM, then extract files from it
- Restore-time efficiency — large VMs take their full size to restore
Default Proxmox backup mode is snapshot which uses storage-layer snapshots if available, falling back to suspend mode. This works without VM downtime for ZFS, LVM-thin, and Ceph storage backends.
Typical hobby pattern: vzdump backups to external USB drive, weekly schedule, keep last 4-6 backups, accept that disk usage grows with retention period. Works fine until backup data exceeds available external storage.
Backup destinations — where backups actually live
A backup is only as good as its destination. Choosing where backups physically live determines what failures they survive.
External USB or eSATA drive connected to the Proxmox host:
- Survives single-disk failure on internal storage
- Doesn’t survive host theft, fire, or coordinated disaster
- Doesn’t survive ransomware if drive stays connected
- Acceptable as the only backup for casual hobby setups
Network attached storage (NAS) via NFS or SMB:
- Survives Proxmox host failure
- Doesn’t survive NAS failure or coordinated disaster
- Doesn’t survive ransomware if mount stays active
- Good middle tier for serious labs
Dedicated PBS host on separate hardware:
- Survives Proxmox cluster failure
- Doesn’t survive coordinated attack reaching PBS host
- Doesn’t survive building-level disasters
- Standard pattern for production-like environments
Offsite/cloud backup:
- Survives most local disasters
- Slower restore (network bandwidth bound)
- Costs money continuously
- Required for the third backup tier (ransomware/disaster protection)
Cold storage (offline media):
- Survives ransomware and active attackers
- Requires manual rotation discipline
- Often skipped, then regretted
- The tier that separates “backup” from “actually protected”
The destination matters more than the tool. PBS to a NAS in the same room is operationally less protective than vzdump to a USB drive that gets stored offsite weekly.
3-2-1 backup rule (and why many homelabs violate it)
The 3-2-1 rule is industry shorthand:
- 3 copies of important data
- 2 different storage media types
- 1 copy offsite (physically separated)
The original Proxmox VMs count as copy 1. A backup to PBS or NAS is copy 2. An offsite copy is copy 3.
Typical hobby backup strategies in practice:
- 2 copies (original + one backup)
- 1 storage media type (all spinning disks or all SSDs)
- 0 copies offsite
This is “backup that works most of the time.” It fails for fire, theft, ransomware, or any disaster affecting the building.
Practical 3-2-1 implementations:
| Tier | Copy 1 | Copy 2 | Copy 3 |
|---|---|---|---|
| Minimum | VMs on Proxmox | Weekly to NAS or USB | Monthly to external drive stored offsite |
| Better | VMs on Proxmox | Daily to PBS | Weekly to cloud backup |
| Serious | VMs on Proxmox cluster | Daily to PBS | Weekly to cloud + monthly to offline media |
The biggest gap in typical strategies is the “1 offsite” piece. It feels disproportionately expensive for hobby use. The honest question: would the data being lost cost more than the offsite storage costs? For people with family photos or business records, yes.
Restore validation — the step everyone skips
Backups age silently. A backup configured in January and never tested by June may be:
- Still working correctly
- Corrupted on storage, undetected
- Pointing to deleted source data
- Encrypted with a password no one remembers
- On a drive that has failed since last write
- In a format the current PBS version no longer reads
The only way to know which one is to actually restore.
What restore testing means in practice:
- Pick a recent backup
- Restore it to a different storage location (not over the source)
- Boot the restored VM
- Verify the data inside looks correct
- Document the restore time and any issues encountered
This takes 30-60 minutes per VM. Doing it once monthly catches most problems before they matter. Doing it once during initial setup and never again is the most common backup mistake.
Field note
Backup dashboards report successful jobs. Restore attempts report reality.
Failure scenario
Restore tested once during initial PBS setup. Six months later, disaster strikes. Encryption password was stored only in a password manager on a laptop that died. The “tested backup” is now unrecoverable encrypted data.
Most operators discover restore problems during emergencies because that’s the first time they actually perform a restore.
Restore-time realism — backup exists, but can you recover fast enough?
“Backup exists” and “recovery within acceptable time” are different problems.
A backup that takes 18 hours to restore protects against eventual data loss but does not provide rapid recovery. Operators discover this during actual disasters: backup ran successfully, restore process started, ETA shows “tomorrow afternoon.”
Disaster recovery is where theoretical backups meet real hardware speed.
Restore time depends on several factors:
Network bandwidth. PBS restore over 1GbE saturates at roughly 110 MB/s. A 500GB VM takes around 90 minutes minimum, often longer with dedup chunk reassembly overhead. Multi-TB VMs take many hours.
Storage I/O on the target. Restoring to spinning disks creates a write bottleneck. Restoring to SSD is faster but consumer SSDs may throttle during sustained writes.
Deduplication restore overhead. PBS deduplicated backups need chunk reassembly during restore. The dedup tradeoff is great for storage savings, less great for emergency restore speed.
Backup chain length. Incremental backups need the chain reconstructed to the target point. Longer chains = slower restores.
Define your RTO before designing the backup strategy, not after disaster:
- Single critical service: hours acceptable? days?
- Family photo archive: weeks acceptable
- Production VM: minutes? hours?
- Test environment: rebuild from scratch is fine
If your acceptable RTO is 1 hour and your restore process actually takes 8 hours, the backup strategy doesn’t meet operational needs even though backups exist.
Reducing restore time:
- Local PBS instance for fast restore, offsite copy for disaster
- 10GbE between Proxmox and PBS for serious environments
- SSD-based PBS storage for fast read paths
- Smaller VMs (split workloads across multiple smaller VMs)
- Pre-staged restore destinations (don’t allocate storage during emergency)
Troubleshooting restore failures
When a restore fails or stalls, the diagnostic flow matters more than the symptoms.
Restore attempt fails or hangs:
1. Check PBS connectivity (ping, port 8007 reachable)
2. Verify backup integrity on PBS side
(proxmox-backup-manager verify <store>)
3. Check target storage free space (df -h, pvesm status)
4. Review restore logs
(/var/log/pve/tasks/, journalctl -u pveproxy)
5. Check for stale locks (qm unlock <vmid>)
6. Verify Proxmox version matches backup version compatibility
7. Try restore to alternate storage
(rules out target-specific issue)For PBS-specific issues:
PBS backup or verify reports errors:
1. Check disk health on PBS storage
(smartctl, zpool status)
2. Run garbage collection
(proxmox-backup-manager garbage-collection start <store>)
3. Run integrity verification
(proxmox-backup-manager verify <store>)
4. Review PBS logs (journalctl -u proxmox-backup)
5. Check available disk space
(PBS needs working space beyond raw backup size)The most common restore failures in homelabs are not corrupted backups. They are missing free space on the restore target, network connectivity issues, or version mismatches between Proxmox and PBS that crept in during updates.
Ransomware-resistant backup strategy
The backup tier that gets skipped most often is the one that matters during active attacks.
The attack pattern: ransomware reaches a system with network access to backup storage. It encrypts source data. It also encrypts all reachable backup files. Backup automation continues running and creates new “backups” that are actually encrypted garbage. Detection happens days later. By then, all online backups are compromised.
Online backups are still online systems.
Network-accessible backups are not ransomware protection. NFS mounts, SMB shares, even credential-protected PBS instances can be reached by code running on the protected systems.
Failure scenario
NAS backups work correctly for months. Daily SMB share mount, scheduled backups, retention policy keeping 30 days. Ransomware encrypts the mounted share before detection. Daily backup job continues running, encrypting older backups via retention rotation. By the time detection happens, the entire 30-day window contains encrypted garbage.
What actually protects against ransomware:
Air-gapped media — backups on storage that is physically disconnected when not actively backing up. External drives rotated weekly. Tape libraries with offline slots. Manual carry-offsite drives.
Immutable storage — cloud backup with write-once-read-many policies, or PBS with retention locks that prevent backup deletion until a defined time period passes.
Out-of-band credentials — backup access keys stored outside the protected network, in password managers or hardware tokens. Compromised user accounts shouldn’t grant backup deletion access.
Short retention windows convert slow corruption into permanent loss. The longer the retention, the higher the chance that at least one usable backup exists when corruption is detected weeks or months after it started.
For practical homelab protection: at minimum, one external drive rotated offsite weekly that contains backups created when it’s connected. The drive lives disconnected most of the time. This single discipline outperforms elaborate immutable cloud strategies that get bypassed via stolen credentials.
Don’t forget the host itself
VM backups dominate backup discussions. The host configuration around them is often skipped.
When a Proxmox host dies and gets rebuilt, restoring VMs is only half the work. The other half is rebuilding everything that made the host functional.
Host-level items that need backup:
/etc/pve/— cluster configuration, VM definitions, HA config, firewall rules, storage definitions/etc/network/interfaces— bridge, VLAN, bonding configuration- Proxmox firewall configs — cluster, node, and per-VM firewall rules
- PBS encryption keys — without these, encrypted backups are unrecoverable
- API tokens — automation credentials for PBS, monitoring, deployment tools
- SSH keys — host keys, authorized_keys for cluster access
- DNS / reverse proxy configs — nginx, Caddy, Traefik configurations outside VMs
- Docker compose files — if you run Docker outside VMs (which most operators don’t, but some do)
- License and subscription info — Proxmox subscription details, PBS subscription, hardware support contacts
Most of these are small files. Total host-level backup is typically under 100MB. The disproportion matters: VM disks might be terabytes, but losing 100MB of configuration can extend cluster rebuild from hours to days.
Practical pattern: weekly tarball of /etc/pve/, /etc/network/, /etc/ssh/, plus any custom config locations. Store it alongside VM backups. Encrypt it if it contains credentials.
The host that backs up VMs perfectly but loses its own configuration is rebuilding from memory after disaster. Memory is unreliable in the middle of disaster recovery.
Common Proxmox backup mistakes
A short list of failures that account for most homelab backup disasters.
Backing up only VM disks, not configuration. Without /etc/pve/, VM disks restore as orphaned files. Always back up host configuration separately.
Trusting backup dashboards. A successful backup job means the file was created. It says nothing about whether the file can be read back, whether the VM inside it boots, whether the data inside is consistent.
Single backup destination. All backups on one NAS. NAS fails. All backups lost simultaneously.
Untested restore procedure. Backups exist. Procedure for restoring documented. Operator never walks through the steps. During disaster, procedure has errors, missing details, or assumes tools that don’t exist anymore.
Backup retention too short. Default “keep last 7” means corruption introduced 8 days ago is no longer recoverable. Some failures are detected late.
Forgetting offsite rotation. Offsite drive set up properly. Rotated for the first month. Then life happens. Six months later, “offsite” drive is sitting on the same desk as the Proxmox host.
PBS on same host as Proxmox. Convenient for setup. Defeats the purpose. PBS must run on different physical hardware for the protection model to work.
Not testing the full restore process. Operators test “can I restore this VM” but not “can I restore this VM from this specific backup to this specific target with these specific credentials in this specific timeframe.”
The backup hierarchy maturity ladder
Backup strategies have an operator maturity progression similar to storage choices.
| Stage | Strategy | Typical situation |
|---|---|---|
| 1 | No formal backup | New homelab, learning phase |
| 2 | Manual occasional copy to external drive | Hobby data, low stakes |
| 3 | Scheduled vzdump to NAS or external drive | Serious homelab, hobby data |
| 4 | PBS to dedicated host with retention policies | Production-like environment |
| 5 | PBS + offsite copy (cloud or rotated drives) | Important data, real RTO requirements |
| 6 | Multi-tier with air-gapped or immutable copy | Business-critical, ransomware-aware |
Many setups sit at Stage 2-3 indefinitely, which is fine for hobby data. Anything irreplaceable deserves Stage 4 minimum. Anything business-critical deserves Stage 5-6.
The progression isn’t strictly linear. Some operators jump from Stage 1 to Stage 4 because they already have PBS experience from work. The point is matching backup investment to actual data value.
What changes for clusters
Cluster backup requirements differ from single-host setups in three ways.
Cluster configuration is the most valuable data. A cluster’s /etc/pve/ contains all VM definitions, cluster topology, HA configuration, storage definitions, firewall rules. Losing it means rebuilding from memory. Back up /etc/pve/ from each node, not just from one.
Live migration affects backup planning. VMs that migrate between nodes may have different storage attached on different nodes. PBS handles this correctly when configured properly, but backup paths need consistent definitions across the cluster.
Cluster restore is multi-step. Restoring a cluster after total failure means: rebuild cluster, restore /etc/pve/, restore VMs from backup, validate cluster state. This is a multi-day procedure for any serious cluster. Document it. Practice it on a test cluster before the production cluster needs it.
HA-enabled VMs add restore complexity. Restoring an HA-managed VM requires either recreating HA configuration or restoring to a non-HA state first and re-enabling HA after.
For typical homelab clusters: weekly vzdump or daily PBS backup of VMs, plus separate backup of /etc/pve/ configuration. The cluster-specific restoration procedure deserves its own documented runbook.