Proxmox Backup: Complete Guide for VMs, CTs, and PBS
Backing up a Proxmox Virtual Environment (VE) correctly means more than clicking a snapshot in the web GUI. This guide explains vzdump, Proxmox Backup Server (PBS), retention policies, and off-site strategies so your home lab or production cluster survives disk failure.
1. VZDump: The Built-In Backup Engine
Proxmox ships vzdump as its native backup tool. It creates consistent snapshots of running containers (LXC) and KVM virtual machines by pausing QEMU briefly, dumping RAM state, and copying the virtual disk.
Supported modes: – Snapshot — freeze filesystem with QEMU guest agent, zero downtime – Suspend — save VM state to disk, brief pause – Stop — shutdown guest first, cleanest backup
Storage targets: local directory, NFS, CIFS, and Proxmox Backup Server
Compression: LZO (fast) or Zstandard (smaller). Zstd is the default since Proxmox 8.
2. Backup a Single VM or CT
Open Datacenter → Backup → Add. Select the node, VMs, and storage target. The default schedule runs at 2:00 AM daily.
For CLI users, a single command backs up VM 100 to local storage:
vzdump 100 --storage local --mode snapshot --compress zstd
To backup all guests on a node:
vzdump $(qm list | awk 'NR>1 {print $1}') --storage backup-nfs --mode snapshot
3. Proxmox Backup Server (PBS): Enterprise Off-Site
PBS is a separate Debian-based appliance that deduplicates backups across VMs. It stores chunk-level data, reducing total backup size by 40-60 percent compared to raw vzdump archives.
Architecture: – One PBS instance per off-site location – Proxmox nodes push backups via HTTPS/8007 – Deduplication happens client-side before transfer
Setup overview: 1. Install PBS on bare metal or inside a VM 2. Add PBS datastore via Datacenter → Storage → Add → Proxmox Backup Server 3. Set encryption key on the client (Proxmox node) 4. Schedule backup jobs pointing to PBS storage
Encryption is mandatory for off-site backups. Without it, root on the PBS host can read every guest filesystem.
4. Retention Policies That Actually Work
The default “keep last 7” fills disks fast. A better strategy:
| Tier | Count | Compression | |——|——-|————-| | Daily | 7 days | Zstandard | | Weekly | 4 weeks | Zstandard | | Monthly | 3 months | LZO for speed |
Configure this in Datacenter → Backup → Retention, or via /etc/vzdump.conf:
keep-last: 7
keep-hourly: 0
keep-daily: 7
keep-weekly: 4
keep-monthly: 3
5. Restore Testing: The Step Everyone Skips
A backup that has never been restored is a liability. Test restore quarterly:
1. Create a new VM ID on isolated storage 2. Restore from vzdump: qmrestore /var/lib/vz/dump/vzdump-qemu-100-*.vma.zst 999 --storage local-lvm 3. Boot VM 999 and verify data integrity 4. Run fsck inside the guest if filesystem errors appear
For PBS, use the web restore browser or:
proxmox-backup-client restore vm/100/2025-01-15T02:00:00Z /target/path
6. Monitoring and Alerting
Backup jobs that fail silently are invisible until you need them. Add notifications:
# /etc/vzdump.conf
mailto: [email protected]
notification: failure, success
Proxmox also exposes backup status in the task log. Integrate with your monitoring stack by parsing /var/log/vzdump/ or querying the API:
pvesh get /nodes/localhost/tasks --output-format json | jq '.[] | select(.type=="vzdump")'
What to Do Now
If your Proxmox environment currently has no scheduled backups, start with vzdump to local storage tonight. Once that works, deploy PBS to a second physical location. The combination of local vzdump archives plus off-site PBS chunks covers every failure mode from accidental deletion to building fire.