Proxmox VE Backup and Snapshot Guide: vzdump, Scheduled Backup Jobs and qmrestore

If you run virtual machines or sell VPS on a dedicated server, Proxmox VE backups and snapshots must be planned before something goes wrong: deleted files, failed upgrades and compromises are all recovered from them. This guide explains the three vzdump backup modes, scheduled backup jobs, restoring with qmrestore and pct restore, snapshots vs backups, what Proxmox Backup Server adds, and how to plan storage space. It applies to Proxmox VE 7.x/8.x; run the commands as root on the host.

Step 1: Check Proxmox Storage and Backup Space

The default local storage (/var/lib/vz) can hold backup files; local-lvm stores VM disks but not backups. Check free space and existing guests first:

pvesm status
df -h /var/lib/vz
qm list
pct list
ls -lh /var/lib/vz/dump/

Step 2: Manual Backups with vzdump (snapshot, suspend, stop Modes)

vzdump is the built-in backup tool. The modes differ as follows:

• snapshot: live backup with no downtime; the most common choice. With the QEMU Guest Agent enabled the filesystem is frozen briefly for better consistency.
• suspend: mainly for containers; data is synced first, then the guest is suspended briefly.
• stop: the guest is shut down, backed up and started again; the most consistent but causes downtime.

# one VM, live, zstd compressed, to storage "local"
vzdump 100 --mode snapshot --storage local --compress zstd

# one container, suspend mode
vzdump 101 --mode suspend --storage local --compress zstd

# stop mode: most consistent, guest is shut down during backup
vzdump 102 --mode stop --storage local --compress zstd

# all guests on this node, with a note
vzdump --all --mode snapshot --storage local --compress zstd --notes-template '{{guestname}} manual'

zstd compression is fast and compact. Files land in /var/lib/vz/dump/ as .vma.zst for VMs and .tar.zst for containers.

Step 3: Create a Scheduled Backup Job with a Retention Policy

In the web UI go to Datacenter → Backup → Add, choose node, storage, schedule, mode and compression, and set how many backups to keep on the Retention tab. The same job from the command line:

# every day 02:30, all guests, keep 7 daily + 4 weekly
pvesh create /cluster/backup --schedule '02:30' --all 1 \
  --storage local --mode snapshot --compress zstd \
  --prune-backups keep-daily=7,keep-weekly=4 --enabled 1

pvesh get /cluster/backup
# preview when a schedule will run
systemd-analyze calendar '02:30'

prune-backups controls automatic cleanup; keep-daily=7,keep-weekly=4 keeps one backup per day for 7 days and one per week for 4 weeks. Without a retention policy, backups pile up until the disk is full.

Step 4: Restore Backups with qmrestore and pct restore

Restore to a new VM ID first, verify the data, then switch over, so the original is not overwritten. To overwrite on purpose, stop the guest and add --force 1:

# list backup files on a storage
pvesm list local --content backup

# restore a VM backup to a NEW id 120 on local-lvm
qmrestore /var/lib/vz/dump/vzdump-qemu-100-2026_10_01-02_30_00.vma.zst 120 --storage local-lvm

# overwrite the existing VM 100 (VM must be stopped)
qm stop 100
qmrestore /var/lib/vz/dump/vzdump-qemu-100-2026_10_01-02_30_00.vma.zst 100 --force 1

# restore a container backup
pct restore 121 /var/lib/vz/dump/vzdump-lxc-101-2026_10_01-02_30_00.tar.zst --storage local-lvm

Step 5: Create and Roll Back Proxmox Snapshots (Snapshots vs Backups)

A snapshot records disk state (and optionally RAM) at a point in time; taking and rolling back take seconds, which is ideal before an OS upgrade or config change. But snapshots live on the same storage as the disk, vanish with it if the drive fails, and grow and slow the disk when kept for long. In short: snapshots are for short-term rollback, backups are for real data protection.

# take a snapshot before an upgrade (add --vmstate 1 to include RAM)
qm snapshot 100 before_upgrade --description "before apt full-upgrade"
qm listsnapshot 100

# roll back if something breaks
qm rollback 100 before_upgrade

# delete it when no longer needed
qm delsnapshot 100 before_upgrade

# containers use pct
pct snapshot 101 before_upgrade
pct rollback 101 before_upgrade

Snapshots need supporting storage such as LVM-thin, ZFS, Ceph or qcow2 on directory storage; plain LVM and raw images do not support them.

Step 6: Proxmox Backup Server and Storage Space Planning

Proxmox Backup Server (PBS) is the dedicated backup server from Proxmox. It offers incremental backups, deduplication, encryption and verification; a daily backup only transfers changed blocks, so space and time are far below full vzdump archives. Typically PBS runs on another server or in another data center, and you add it under Datacenter → Storage → Add → Proxmox Backup Server with its address, datastore, user and fingerprint.

# after adding the PBS storage in Datacenter -> Storage, check it
pvesm status
# back up to it like any other storage (named "pbs1" here)
vzdump 100 --mode snapshot --storage pbs1

Rough sizing for vzdump: used data per guest × compression ratio (zstd is usually 0.4–0.7) × number of copies kept, plus 20% headroom. Ten guests with 20 GB used, keeping 7 copies, need about 10 × 20 × 0.6 × 7 ≈ 840 GB. With PBS deduplication it is usually much less.

FAQ

Snapshot-mode backup says "guest-agent not running"

The QEMU Guest Agent option is enabled on the VM but the agent is not running inside it. Install and start qemu-guest-agent (apt on Debian/Ubuntu, dnf on CentOS/Rocky/AlmaLinux) or disable the option in Proxmox.

Backups filled up the local storage

Set a sensible retention policy on the job, remove old archives you no longer need from /var/lib/vz/dump/ (double-check before deleting), or move the backup target to a separate disk or PBS.

Are snapshots alone enough?

No. Snapshots depend on the original storage and disappear with it on disk failure, corruption or VM deletion. Keep at least one backup on a different disk or server.

Still stuck? Open a ticket with IMIDC 24/7 technical support: https://www.imidc.com/submitticket.php