Proxmox VE has a backup engine built in. It’s called vzdump, it backs up both KVM virtual machines and LXC containers, and you drive it from the web GUI or the command line. There’s nothing to install and no third-party agent inside the guest.
This guide covers the parts that actually matter day to day: the three backup modes and when each one is safe, how to schedule jobs, where to send the files, how to restore a VM (including to a fresh VMID for testing), and how retention keeps your storage from filling up. The steps target Proxmox VE 8.x; the 7.x workflow is nearly identical apart from a few menu labels.
One thing to settle up front: a backup that lives only on the same host as the VM is a convenience, not a disaster recovery plan. If the host dies, both go with it. Plan for at least one copy on separate storage.
The three backup modes
Every vzdump backup runs in one of three modes. The mode decides how the disk is captured and how much the running VM is disturbed.
vzdump backup modes for VMs
| Snapshot | VM keeps running. Proxmox takes a point-in-time copy of the disk and backs that up. Zero downtime, but the guest filesystem can be mid-write unless the QEMU guest agent is installed to flush it. |
|---|---|
| Suspend | VM is paused for the duration of the backup, then resumed. More consistent than a bare snapshot, but the workload is frozen the whole time. |
| Stop | VM is shut down cleanly, backed up, then powered back on. Fully consistent and simple, at the cost of real downtime. |
For most live systems, snapshot mode is the right default — no downtime, and with the guest agent it’s consistent enough for general workloads. Stop mode is the safe choice for anything you can’t risk catching mid-write, like a database server without application-aware quiescing, when a short maintenance window is acceptable. Suspend mode is the odd one out; it’s mostly useful for containers or VMs where snapshot isn’t available on the underlying storage.
Run a one-off backup
Before automating anything, take a manual backup so you know the storage target works.
In the GUI, select the VM, open the Backup tab, and click Backup now. Choose the target storage, the mode, and the compression, then start it. The task log streams as it runs.
From the command line, vzdump takes the VMID:
# back up VM 101 to local storage, snapshot mode, zstd compression
vzdump 101 --storage local --mode snapshot --compress zstdYou can back up several VMs at once, or every VM on the node:
# back up specific VMs
vzdump 101 102 105 --storage backup-nfs --mode snapshot --compress zstd
# back up all VMs on this node, excluding a couple
vzdump --all --exclude 999,1000 --storage backup-nfs --mode snapshotThe result is a single file named like vzdump-qemu-101-2026_07_07-02_15_03.vma.zst. The qemu part marks it as a VM (containers get lxc), and the timestamp is when the job ran.
Choosing a storage target
vzdump can only write to storage that has the VZDump backup file content type enabled. Set that under Datacenter → Storage, then edit the storage and tick the backup content type.
Where to send Proxmox backups
| Local directory | Default local storage at /var/lib/vz/dump. Fast and simple. Useless if the host hardware fails — keep it as a first tier only. |
|---|---|
| NFS / CIFS share | A NAS or file server on the network. Survives a host failure and is easy to set up. Good general-purpose target. |
| Proxmox Backup Server | Dedicated backup appliance. Adds deduplication, incremental backups, client-side encryption, and verification. The right answer once you have more than a couple of hosts. |
For a homelab or a single host, an NFS share on a NAS is usually enough. Once you’re running several nodes or your backup window gets long, Proxmox Backup Server earns its place: it only ships changed blocks, so daily backups of a large VM take minutes instead of writing the whole disk each time.
Schedule automatic backups
A backup you have to remember to run isn’t a backup. Proxmox schedules jobs at the Datacenter level so they cover whichever node a VM lives on.
Go to Datacenter → Backup and click Add. You configure:
- Storage — the backup target.
- Schedule — when it runs, using a calendar format like
02:00for daily at 2 AM, ormon..fri 21:00for weekday evenings. - Selection mode — pick specific VMs, all VMs, or all-except a list. The “all” and “exclude” options auto-include new VMs, which is handy so a freshly built machine isn’t silently left unprotected.
- Mode — snapshot, suspend, or stop.
- Compression and retention (covered below).
The schedule uses systemd calendar syntax. A few common ones:
02:30 # every day at 02:30
mon..fri 21:00 # weekdays at 21:00
sun 03:00 # Sundays at 03:00
*/6:00 # every 6 hours, on the hourSet retention so backups don’t pile up
Without retention, every run adds another file and the storage eventually fills — at which point new backups fail and you’re suddenly unprotected. Proxmox handles this with prune rules that keep a tiered set of recent backups and delete the rest after each successful run.
The keep options stack, so you can hold many recent backups and progressively fewer older ones:
Retention (prune) options
| keep-last | Keep the N most recent backups regardless of age |
|---|---|
| keep-daily | Keep one backup per day for N days |
| keep-weekly | Keep one per week for N weeks |
| keep-monthly | Keep one per month for N months |
| keep-yearly | Keep one per year for N years |
A sensible everyday policy might be: keep the last 3, plus one daily for 7 days, one weekly for 4 weeks, and one monthly for 6 months. In a CLI job that looks like:
vzdump 101 --storage backup-nfs --mode snapshot \
--prune-backups 'keep-last=3,keep-daily=7,keep-weekly=4,keep-monthly=6'In the GUI, the same fields appear under the backup job’s Retention tab. Set them there and Proxmox prunes automatically after each run.
Restore a VM from a backup
Restoring is the part you actually care about, so it’s worth knowing both the click path and the command.
In the GUI, open the storage that holds the backup and go to its Backups tab (or select the VM and use its Backup tab). Pick the backup file, click Restore, then choose:
- Target VMID — the original ID to overwrite it in place, or a new unused ID to restore alongside the original.
- Target storage — where the restored disks land.
- Unique — regenerate MAC addresses, useful when restoring a clone so it doesn’t clash with the original on the network.
From the CLI, qmrestore rebuilds a VM from a .vma file:
# restore into a brand-new VM with ID 150
qmrestore /var/lib/vz/dump/vzdump-qemu-101-2026_07_07-02_15_03.vma.zst 150
# restore over the existing VM 101 (must already be stopped); force overwrite
qmrestore /mnt/pve/backup-nfs/dump/vzdump-qemu-101-2026_07_07-02_15_03.vma.zst 101 --forceContainers use pct restore with the same idea. After a restore, check the VM’s network settings and, if it was a clone, confirm the MAC and hostname before powering it on so two identical machines don’t fight over the same IP.
A backup routine that holds up
Putting it together, a setup that survives real failures looks like this:
Proxmox backup checklist
- QEMU guest agent installed and enabled on VMs you back up in snapshot mode
- A scheduled Datacenter backup job, not manual runs
- Backups written to storage separate from the host (NFS, CIFS, or Proxmox Backup Server)
- Retention rules set so old backups prune automatically
- At least one copy off-site or on a second device
- A restore tested to a spare VMID in the last month
The storage choice you made at install time affects how snapshot mode behaves, since not every backing store supports VM snapshots the same way. If you’re unsure what you’re running on, Proxmox LVM vs LVM-Thin vs ZFS breaks down the differences. And if you haven’t set the host up yet, start with installing Proxmox VE on bare metal.
Get the schedule, the off-host target, and the retention right, then prove it with one test restore. After that, backups stop being something you worry about. For more walkthroughs, browse the Proxmox guides.
