How to Backup Proxmox to Cloud: PBS vs VZDump
Proxmox gives you two main ways to backup your VMs: the traditional vzdump tool (which has been around forever) and the newer Proxmox Backup Server (PBS). Both can back up to cloud storage, both protect your data, but they work completely differently under the hood.
If you're trying to decide which to use, or wondering whether to migrate from vzdump to PBS, this guide breaks down exactly how each works, their performance characteristics, and when to use each one.
The Quick Answer
TL;DR:
- VZDump: Traditional full backup tool, creates single archive files (.vma.zst or similar), works everywhere, simple but less efficient
- PBS: Modern deduplicated backup system, stores data as chunks, much more efficient for multiple/incremental backups, requires PBS server
For most users: Use PBS if you can. It's significantly better for regular automated backups. Use vzdump for one-off backups or when you need simple portable archives.
What Is VZDump?
VZDump is Proxmox's original backup utility. It's been part of PVE since the beginning and still works great for many use cases.
How VZDump Works
When you run a vzdump backup:
- Creates a snapshot of your VM (in snapshot mode)
- Reads all the VM data
- Compresses it into a single archive file
- Writes that file to your backup storage
- Done
The result is one file per backup. A 100GB VM becomes a 40GB .vma.zst file (with compression).
VZDump Characteristics
Pros:
- Simple to understand (one VM = one backup file)
- Portable archives (can move them anywhere)
- No additional infrastructure required
- Works with any storage that can hold files
- Fast for single backups
Cons:
- Every backup is full-size (incremental not really a thing)
- No deduplication (identical data is stored multiple times)
- Can be slow for large VMs
- Wastes storage space over time
- No built-in verify functionality
Typical use cases:
- One-off backups before major changes
- Portable backups you need to move
- Simple setups with few VMs
- Where storage space is cheap
What Is Proxmox Backup Server (PBS)?
PBS is Proxmox's modern backup solution, released in 2020. It's designed specifically for efficient, scalable VM backups.
How PBS Works
PBS uses a completely different architecture:
- Creates a snapshot of your VM
- Reads VM data in fixed-size chunks (4MB by default)
- Calculates hash for each chunk
- Checks if that chunk already exists in backup storage
- Only uploads chunks that don't exist
- Stores metadata about which chunks belong to which backup
PBS Characteristics
Pros:
- Massive deduplication (60-90% space savings typical)
- Incremental forever (only changed data is transferred)
- Built-in verification
- Content-addressed storage (data corruption is detectable)
- Snapshot catalog for granular file recovery
- Much faster for multiple backups over time
- Bandwidth-efficient
Cons:
- Requires PBS server infrastructure
- More complex to set up initially
- Not as portable (can't just copy files around)
- Slightly more overhead for single backups
Typical use cases:
- Regular automated backups
- Multiple VMs with similar OS/data
- Limited storage or bandwidth
- Production environments
- Anything where you want incremental backups
Performance Comparison
Let's look at real-world performance differences.
Test Setup
- Test VM: Ubuntu 22.04 with 100GB disk (60GB used)
- Changes between backups: 5GB of data modified
- Network: 1Gbps connection
- Storage: Both writing to same NAS over NFS
First Full Backup
Initial Backup Performance
| Metric | VZDump Traditional backup | PBS Chunk-based backup |
|---|---|---|
Backup Time Time to complete | 28 minutes | 32 minutes |
Storage Used Space consumed on backup storage | 42GB | 38GB |
Network Usage Data transferred over network | 42GB transferred | 38GB transferred |
CPU Usage Average CPU load during backup | 45-60% | 50-70% |
For the first backup, performance is comparable. VZDump might be slightly faster because there's less overhead, but the difference is minimal.
Second Backup (5GB Changed)
Now the difference becomes clear:
Incremental Backup Performance
| Metric | VZDump Full backup again | PBS Incremental chunks |
|---|---|---|
Backup Time Time to complete | 27 minutes | 4 minutes |
Additional Storage New space consumed | 41GB | 3.2GB |
Network Usage Data transferred | 41GB transferred | 3.2GB transferred |
Total Storage Space for both backups | 83GB | 41GB |
This is where PBS shines. Because only changed chunks are transferred and stored, the second backup is dramatically faster and more efficient.
30 Days of Daily Backups
Let's extend this to a month of daily backups with typical changes (5-10GB/day):
VZDump:
- 30 full backups × 42GB each = 1,260GB total storage
- 30 backups × 28 minutes = 14 hours total backup time
- 30 × 42GB = 1,260GB network bandwidth used
PBS:
- Initial 38GB + (29 incremental × 4GB average) = 154GB total storage
- Initial 32 min + (29 × 4 min) = 2.5 hours total backup time
- 87% less storage used
- 82% less backup time
- 87% less bandwidth used
Deduplication Impact
PBS's deduplication means 30 days of backups use roughly the same space as 3-4 vzdump backups. For environments with multiple similar VMs, the savings are even more dramatic.
Deep Dive: How Deduplication Works
PBS's secret weapon is content-addressed storage with deduplication. Here's how it actually works:
Chunk-Based Storage
PBS splits your VM disk into fixed-size chunks (4MB default). Each chunk gets a SHA-256 hash calculated.
VM Disk (100GB)
├── Chunk 1 (4MB) → Hash: aa3f8c2...
├── Chunk 2 (4MB) → Hash: bb7d2e1...
├── Chunk 3 (4MB) → Hash: aa3f8c2... ← Same as Chunk 1!
├── Chunk 4 (4MB) → Hash: cc9a1f4...
└── ...
When Chunk 3 has the same hash as Chunk 1, PBS doesn't store it twice. It just references the existing chunk.
Why This Is Powerful
Between backups: Only changed chunks need to be stored. If you modify one file in a VM, maybe only 2-3 chunks change. The rest reference existing chunks from previous backups.
Between VMs: If you have 10 Ubuntu 22.04 VMs, the OS itself is largely identical. Those chunks are stored once and referenced 10 times.
Compression is still applied: Each chunk is compressed before storage, so you get compression savings on top of deduplication savings.
Real-World Example
Let's say you have:
- 5 Ubuntu 22.04 VMs
- 3 Debian 11 VMs
- 2 Windows Server 2022 VMs
Without deduplication:
- Each VM is 50GB
- 10 VMs × 50GB = 500GB raw
- With compression: ~250GB stored
- After 7 days of daily backups: ~1.75TB
With PBS deduplication:
- First Ubuntu VM: 50GB raw, stores ~22GB compressed
- Second Ubuntu VM: 50GB raw, but 70% is duplicated from first VM, stores ~7GB additional
- Remaining Ubuntu VMs: ~5GB each additional
- Similar for Debian and Windows VMs
- First full backup set: ~120GB instead of ~250GB
- After 7 days: ~200GB instead of ~1.75TB
That's 88% less storage used.
Bandwidth Considerations
For cloud backups, bandwidth matters. A lot.
VZDump to Cloud
Every backup transfers the full compressed VM size:
100GB VM with 40% compression = 60GB per backup
Daily backups = 60GB × 30 = 1.8TB/month bandwidth
On a 100Mbps connection:
60GB = 480,000 megabits
480,000 Mb ÷ 100 Mbps = 4,800 seconds = 80 minutes per backup
That's manageable for one VM. Scale to 10 VMs and you're looking at 13+ hours of backup time per day, consuming 18TB/month of bandwidth.
PBS to Cloud
First backup: Same as vzdump (full transfer)
Subsequent backups: Only changed chunks
100GB VM, 5GB changed daily = ~2-3GB compressed chunks transferred
Daily backups = 3GB × 30 = 90GB/month (after initial)
On a 100Mbps connection:
3GB per backup = 4 minutes
10 VMs = 40 minutes total backup time
Bandwidth: ~300GB/month (after initial seeding)
For cloud backups, PBS is essential if you have:
- Slow upload speeds
- Data caps
- Multiple VMs
- Large VMs
When to Use VZDump
Despite PBS being better for most scenarios, vzdump still has its place:
One-Off Backups
Before a risky upgrade or major configuration change:
vzdump 100 --storage local --mode snapshot --compress zstd
Quick, simple, no fuss. Creates a portable backup file you can keep or move elsewhere.
Portable Backups
Need to move a VM to another system without PBS?
VZDump creates a single file you can:
- Copy to USB drive
- Transfer via rsync
- Upload to simple cloud storage
- Import on any Proxmox system
Simple Environments
If you have:
- Just 1-2 VMs
- Plenty of storage
- Infrequent backups
- No deduplication benefits (all different VMs)
Then vzdump might be simpler than setting up PBS infrastructure.
Backup Before PBS Migration
Ironically, use vzdump to backup your VMs before migrating to PBS. Safety first.
When to Use PBS
Use PBS when you have:
Regular Automated Backups
Daily or more frequent backups benefit massively from deduplication. The storage and bandwidth savings pay for the setup complexity within weeks.
Multiple Similar VMs
5 web servers running the same OS? 10 desktop VMs for users? PBS deduplication will save 70-90% storage on those.
Limited Bandwidth
Slow internet connection? PBS incremental backups might transfer 1/10th the data of vzdump.
Limited Storage Budget
PBS can fit 3-4x more backup history in the same storage space through deduplication.
Cloud or Offsite Backups
For any remote backup scenario, PBS is dramatically more efficient.
Long-Term Retention
Need to keep months or years of backups? PBS makes this practical through deduplication. VZDump would eat absurd amounts of storage.
Setting Up PBS for Cloud Backups
If you're convinced PBS is the way to go, here's a quick setup guide for cloud backups:
Option 1: Managed PBS (Easiest)
Use a managed PBS service like Remote-Backups.com:
- Sign up for account
- Create datastore
- Add to Proxmox as PBS storage
- Create backup job
- Done
No server to manage, automatic updates, infrastructure handled for you.
Option 2: PBS on Cloud VPS
Run your own PBS instance in the cloud:
- Spin up a VPS (2 cores, 4GB RAM minimum)
- Install Proxmox Backup Server
- Add cloud storage (S3, local disk, whatever)
- Configure from Proxmox VE
- Set up backup jobs
More control, but you manage the PBS server yourself.
Option 3: Local PBS + Cloud Sync
Run PBS locally for fast backups, sync to cloud for offsite:
- Install PBS on local hardware
- Configure as backup target for Proxmox
- Set up remote sync to cloud storage
- Backups go to local PBS (fast)
- PBS syncs to cloud (automatic, in background)
Best of both worlds but most complex setup.
Migration Guide: VZDump to PBS
Already using vzdump and want to switch? Here's how:
Step 1: Set Up PBS
Either use managed PBS or install your own PBS server.
Step 2: Test with Non-Critical VMs
Don't migrate everything at once:
- Pick a test VM
- Add PBS storage to Proxmox
- Create backup job for test VM to PBS
- Run backup and verify
- Test restore
- Confirm everything works
Step 3: Parallel Running
Run both vzdump and PBS backups for a week:
- Keep existing vzdump jobs
- Add new PBS jobs
- Monitor both
- Compare storage usage and times
- Verify PBS backups work
Step 4: Migrate Production VMs
Once confident:
- Update backup jobs to use PBS
- Disable old vzdump jobs (don't delete yet)
- Let PBS backups run for a week
- Keep one final vzdump backup as safety
- Delete old vzdump backups after PBS proven stable
Step 5: Cleanup
After a month of successful PBS backups:
- Remove vzdump backup jobs
- Delete old vzdump archives
- Update documentation
- Reclaim storage space
Keep Safety Backups
During migration, maintain at least one recent vzdump backup of critical systems until you're 100% confident in PBS. Better safe than sorry.
Troubleshooting Common Issues
PBS Backup Slow Despite Deduplication
Possible causes:
- CPU bottleneck: Deduplication and compression are CPU-intensive
- Network latency: High latency to PBS server slows chunk uploads
- First backup: First backup of a VM is always full-speed (no dedup yet)
Solutions:
- Check CPU usage during backup
- Run PBS network benchmark:
proxmox-backup-client benchmark - Verify it's not the first backup
- Consider faster network or local PBS
VZDump Faster Than PBS?
If vzdump is beating PBS on backup time, you're probably:
- Comparing first-ever backups (both are similar speed)
- Not benefiting from deduplication (all-unique data)
- CPU-bottlenecked on PBS
For single large backups of unique data, vzdump can be faster. But for repeated backups, PBS will be faster by the second or third run.
PBS Using More Storage Than Expected
Check deduplication ratio in PBS web interface. If it's lower than expected:
- VMs might be more unique than you thought
- Encryption can prevent deduplication
- Check for VMs with randomized data (databases, swap)
Cannot Restore from PBS
Make sure:
- PBS server is online and accessible
- Fingerprint matches
- Credentials are correct
- Backup actually completed successfully
Check PBS logs and task history for details.
Conclusion
Use PBS for:
- Regular automated backups
- Multiple VMs
- Limited storage or bandwidth
- Cloud/offsite backups
- Long-term retention
Use VZDump for:
- One-off backups
- Portable archives
- Simple single-VM setups
- Maximum compatibility
For most Proxmox users, PBS is the better choice. The initial setup complexity is worth it for the massive storage and bandwidth savings. But vzdump still has its place for specific use cases.
If you're running production workloads or more than 2-3 VMs, invest the time to set up PBS. Your storage costs and backup times will thank you.




