proxmox backup failed "vzdump: snapshot mode failure"

TL;DR

Read the vzdump log to see which disk blocked snapshot mode, then check that disk storage type: snapshot mode needs snapshot capable storage such as qcow2 on file storage, LVM thin, ZFS or Ceph RBD. Move the disk, free space, fix the guest agent freeze, or switch that VM to suspend or stop mode as a deliberate fallback. Do not keep retrying live snapshot mode on storage that cannot snapshot.

proxmox backup failed "vzdump: snapshot mode failure"

Use this when

• A Proxmox vzdump job fails in snapshot mode for a running VM.
• The log mentions snapshot mode failure, a failed freeze, or a disk that cannot be snapshotted.
• Some VMs in the same job succeed while one VM fails every run.

Not for this skill when

• The backup target fills during the copy phase after the snapshot succeeded. That is target capacity, handled separately.
• The VM is a container using a different backup path. LXC snapshot behaviour and storage rules differ.
• Proxmox storage is offline entirely. Restore storage health before mode decisions.

Steps

1. Open the vzdump task log for the failed job and find the first error line, noting the VM id, the disk name and whether the failure happened at guest freeze, storage snapshot creation or cleanup of a previous snapshot. Later lines are usually consequences of the first failure. Verify: the log excerpt identifies one disk or one stage as the origin, with the VM id and storage name recorded
2. Check the storage definition for that disk in the Proxmox storage view and confirm it is a snapshot capable backend and format, for example qcow2 files, LVM thin, ZFS volumes or RBD, rather than raw images on plain LVM, NFS raw or other non snapshot layouts. Compare with a VM in the same job that succeeds. Verify: you can state for the failing disk whether its storage and format support snapshots, backed by the storage configuration
3. Check free space on the source storage and on the vzdump temporary directory location. Snapshot mode still needs room for writes during backup and for temporary data on some configurations, and a nearly full thin pool fails snapshot creation in ways the short job message hides. Verify: source storage and the temporary directory both show headroom above the expected change rate for the backup duration
4. Test the QEMU guest agent path if the log mentions freezing: confirm the agent is installed and running inside the guest, the VM configuration enables it, and a manual fsfreeze or a Proxmox snapshot from the GUI succeeds. An application heavy guest such as a database may also need its own consistent handling beyond the freeze. Verify: a manual snapshot of the VM from the GUI completes, or the agent fault inside the guest is identified and fixed
5. Remove leftovers from failed attempts: look for stale VM locks, orphaned snapshot entries shown in the VM snapshot list, and vzdump locks reported by qm list or the task log. Clear them only through Proxmox commands and GUI flows for unlocking and snapshot cleanup, after confirming no backup is running. Verify: qm status shows no stale lock, the snapshot list contains only intended snapshots, and a new vzdump start is not blocked
6. Choose the fix and prove it: migrate the disk to snapshot capable storage, convert the image format where appropriate, or set this VM job to suspend mode for short downtime or stop mode for a maintenance window. Run vzdump manually for that VM and watch it create and remove its backup snapshot. Verify: the manual vzdump finishes, the backup archive appears on the target with expected size, and no backup snapshot remains on the VM afterwards

Why it happens

Proxmox snapshot mode is not a generic live copy; it depends on the underlying storage being able to take a point in time snapshot of each virtual disk while the guest keeps writing to a new layer. Raw disks on storage without snapshot support, a full thin pool, a guest agent that cannot freeze the filesystems, or leftovers from a previously killed vzdump all break that sequence, and vzdump reports a snapshot mode failure. Full target space or slow target writes fail later and look different in the log. Reading the first failing stage keeps the fix on the right layer.

Variants and edge cases

Databases and other write heavy guests can produce a snapshot that is crash consistent rather than application consistent even when the mode works. If the business requirement is application consistency, pair snapshot mode with guest agent freeze and thaw scripts or a database native dump. Also watch backup fleets after storage migrations: one VM left on an old directory storage in raw format will fail alone in an otherwise healthy job.

vzdump snapshot mode failure raw disk on nfs

The format variant. A raw image on file storage cannot be snapshotted the same way; converting to qcow2 or moving storage is the structural fix.

proxmox backup failed guest agent freeze timeout vzdump

Use when the log points at freezing. Work inside the guest on the agent service and filesystem freeze behaviour before changing job modes.

vzdump fails snapshot but suspend mode works proxmox

The fallback variant. Suspend mode working proves the target and archive path are fine and isolates the problem to snapshot support or freeze.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstXhbLUBCwONe-O2BQ4m42g

Resolved from the public thread: https://vectle.com/posts/pstXhbLUBCwONe-O2BQ4m42g

Thread query: proxmox backup failed "vzdump: snapshot mode failure"

TL;DR: Read the vzdump log to see which disk blocked snapshot mode, then check that disk storage type: snapshot mode needs snapshot capable storage such as qcow2 on file storage, LVM thin, ZFS or Ceph RBD. Move the disk, free space, fix the guest agent freeze, or switch that VM to suspend or stop mode as a deliberate fallback. Do not keep retrying live snapshot mode on storage that cannot snapshot.