In Proxmox, a snapshot is a point-in-time record of a VM or container on storage that supports snapshots. It is primarily a rollback mechanism, not a full independent copy of the guest. The important practical point is that snapshots are very useful for short-term safety before changes, but they should usually be removed once they are no longer needed.

How Proxmox snapshots work

At a high level, a snapshot freezes the current view of a disk and then tracks later changes separately.

What happens when a snapshot is taken

1. Proxmox records the current state of the virtual disk.
2. The existing blocks are treated as the “old” state.
3. Any new writes after that point are written in a way that preserves the old data for the snapshot.
4. If the snapshot includes memory, Proxmox also saves the VM RAM and device state so the VM can be resumed exactly where it was.

This is usually done using copy-on-write or redirect-on-write behaviour, depending on the storage backend.

What this means in practice

• The snapshot is not usually a full second copy of the whole disk at creation time.
• It starts small, then grows as the guest changes data.
• The more the VM changes after the snapshot, the larger the snapshot delta becomes.
• Multiple snapshots create multiple points in time, which increases complexity.

Storage backend matters

Proxmox presents snapshots in a similar way in the GUI, but the underlying implementation depends on the storage type:

• qcow2 file storage:
• Uses snapshot metadata and changed block tracking within the disk format.
• Can suffer noticeably from longer snapshot chains.

• ZFS:
• Uses native ZFS snapshots.
• Usually handles snapshots more efficiently than qcow2, but snapshots still keep old blocks alive and can affect space usage and housekeeping.

• LVM-thin:
• Uses thin-provisioned snapshot functionality.
• Efficient for short-lived snapshots, but heavy change rates can make snapshot overhead more visible.

• Ceph RBD:
• Uses native RBD snapshots/layering.
• Well suited to snapshots, but they still add metadata and retained data blocks.

The same general principles also apply to LXC containers where the underlying storage supports snapshots.

Why snapshots can become a performance issue

Snapshots add overhead because the storage layer now has to preserve older block versions as well as serve the current live disk.

Write performance impact

Writes are where snapshots usually hurt most.

Without snapshots, the VM writes directly to its current blocks.

With snapshots in place:

• overwriting an existing block often requires the old version to be preserved;
• new blocks may need to be allocated elsewhere;
• extra metadata has to be updated;
• the disk layout becomes more fragmented over time.

This creates:

• more I/O operations;
• more metadata work;
• more random access patterns;
• higher latency, especially on busy or slower storage.

Read performance impact

Reads can also slow down, particularly with multiple snapshots.

The storage may need to:

• check the current layer first;
• then resolve whether the required data is in the active layer or an older snapshot layer;
• traverse a longer metadata chain.

The result is:

• additional lookup work;
• reduced cache efficiency;
• slower reads in some workloads.

Space usage impact

Snapshots keep old blocks alive.

That means:

• deleting data inside the guest does not necessarily free storage immediately;
• changed blocks that existed when the snapshot was taken must remain available;
• storage can fill up much faster than expected.

This is one of the biggest operational risks. A VM with a long-lived snapshot can consume far more backend storage than the guest operating system appears to be using.

The effect gets worse over time

A very short-lived snapshot taken before an upgrade is usually fine.

A snapshot left in place for days, weeks or months is far more likely to cause:

• growing delta sizes;
• worsening fragmentation;
• slower I/O;
• increased backup and replication overhead;
• unexpected storage exhaustion.

Why deleting snapshots when no longer needed is good practice

Deleting a snapshot removes that historical point-in-time state. On some backends this is effectively a merge or coalesce operation; on others it is more like dropping snapshot references and freeing blocks that are no longer needed. In everyday administration, it is common to refer to all of this as “merging” snapshots.

Benefits of removing old snapshots

• Improved performance
• Fewer snapshot layers means less overhead on reads and writes.

• Reduced fragmentation
• The active disk path becomes simpler.

• Lower storage consumption
• Blocks kept only for old snapshots can be released once no longer referenced.

• Less operational risk
• Reduced chance of a datastore filling up because an old snapshot is preserving large amounts of changed data.

• Cleaner VM management
• Simpler migrations, clones, and day-to-day administration.

Important caution

Deleting a large snapshot can itself be storage-intensive.

During snapshot deletion or consolidation:

• I/O may temporarily increase;
• latency may rise;
• the operation can take time on large or busy disks.

For that reason, deleting large or old snapshots is best done during quieter periods if possible.

Why snapshots are not the same as backups

A snapshot is a rollback point on the same storage platform.

A backup is a separate copy intended for recovery, ideally stored elsewhere.

Key differences:

• A snapshot depends on the original storage remaining healthy.
• A snapshot does not protect against storage failure, corruption of the storage pool, or accidental deletion of the whole VM.
• A backup is designed to be portable and restorable independently of the original running disk chain.

This is why snapshots are best used for:

• pre-upgrade safety;
• short-term testing;
• rollback before risky application or OS changes.

They are not a replacement for proper backups.

Why vzdump does not back up snapshots

vzdump backs up the current VM or container state, not the guest’s whole snapshot history.

What vzdump includes

Typically, vzdump captures:

• the current contents of the guest disks;
• the VM or container configuration;
• enough metadata to recreate the guest on restore.

What it does not include

It does not normally preserve:

• the snapshot tree;
• historical rollback points;
• storage-specific snapshot metadata;
• snapshot layer relationships;
• RAM state from snapshots.

Why this is intentional

There are several good reasons:

• Storage independence
• Proxmox backups are intended to restore onto different storage types.
• A snapshot chain from ZFS, LVM-thin, Ceph RBD, or qcow2 is not a universal portable format.

• Simplicity and reliability
• Backing up the current guest state is far simpler and more predictable than trying to serialise every snapshot and its relationships.

• Smaller and cleaner restores
• Most restores are intended to bring back the VM as it was “now”, not to recreate a whole history of temporary rollback points.

• Avoiding unnecessary bulk
• Old snapshots may contain a large volume of retained blocks and possibly memory state, greatly increasing backup size and restore complexity.

Why a restore comes back without snapshots

A restore from vzdump recreates the guest as a normal VM or container from the backed-up current data.

In other words:

• Proxmox creates fresh target disks;
• it writes the backed-up data into those disks;
• it restores the guest configuration;
• it does not rebuild the original snapshot chain.

So after restore:

• the VM works normally;
• the guest data matches the backed-up point in time;
• previous snapshots are gone.

This is expected behaviour, not a fault.

Why this is useful

Restoring without snapshots is usually the correct outcome because:

• the restored VM is cleaner and simpler;
• there is no inherited snapshot overhead;
• the restore can target a different storage backend;
• the result is a straightforward working guest, not a complicated historical disk graph.

A common point of confusion: vzdump “snapshot mode”

vzdump can run in a mode often referred to as snapshot mode, such as snapshot, suspend, or stop.

This does not mean it is backing up your existing Proxmox snapshots.

What it means is:

• Proxmox may create a temporary snapshot or otherwise freeze I/O long enough to get a consistent backup of a running guest;
• the backup still contains the current guest state only;
• the temporary mechanism used to make the backup consistent is not preserved as part of the restored VM.

So:

• backup mode using snapshots is one thing;
• preserving a VM’s whole snapshot history inside the backup is something else entirely, and vzdump does not normally do that.

Recommended practice

For most environments, the safest and most efficient approach is:

• Take a snapshot immediately before a risky change.
• Keep it only for as long as needed to confirm the change was successful.
• Delete it promptly once rollback is no longer required.
• Do not keep long chains of old snapshots unless there is a specific short-term operational reason.
• Use proper backups, such as vzdump or Proxmox Backup Server, for disaster recovery and retention.
• Watch storage free space carefully when snapshots exist.
• Expect some temporary I/O load when deleting large snapshots.

Summary

• Proxmox snapshots are point-in-time rollback states, not full independent backups.
• They work by preserving old block versions while new writes are stored separately.
• This introduces read, write, metadata, and space overhead, especially when snapshots are large, numerous, or long-lived.
• Deleting snapshots once they are no longer needed reduces overhead, lowers storage risk, and keeps VM performance cleaner.
• vzdump backs up the current guest state and configuration, not the guest’s snapshot history.
• A restore therefore produces a normal VM without snapshots, which is the expected and desirable result in most cases.