Proxmox Snapshot Management: Best Practices

What Are Snapshots in Proxmox?

A snapshot captures the exact state of a virtual machine or container at a specific moment in time. Think of it as a bookmark you can return to if something goes wrong. Unlike backups, snapshots are instantaneous to create and live on the same storage as the original VM, making them ideal for quick protection before risky operations like software upgrades or configuration changes.

However, snapshots are not a replacement for backups. Understanding the differences and knowing when to use each is essential for managing your Proxmox environment effectively.

How QEMU Snapshots Work

When you take a snapshot of a QEMU/KVM virtual machine on file-based or thin-provisioned storage, Proxmox creates a copy-on-write overlay. The original disk image is frozen, and all new writes go to a separate overlay file. This makes snapshot creation nearly instant regardless of disk size.

What Gets Captured

• Disk state: The contents of all virtual disks at the moment of the snapshot
• VM configuration: CPU, memory, network, and all hardware settings
• RAM state (optional): If the VM is running and you include RAM, the snapshot captures the live memory state, allowing you to resume exactly where you left off

# Create a snapshot with RAM state included
qm snapshot 100 before-upgrade --description "Before upgrading to v3.0" --vmstate

# Create a snapshot without RAM (disk + config only)
qm snapshot 100 clean-install --description "Fresh OS install"

Including RAM state takes longer and uses more storage, but it gives you a perfect restore point where the VM resumes exactly as it was, with all running processes and open connections intact.

How ZFS Snapshots Work

If your VM disks live on ZFS storage, Proxmox uses native ZFS snapshots instead of QEMU overlays. ZFS snapshots work at the filesystem level using copy-on-write, and they are handled by the ZFS subsystem rather than QEMU.

The key differences from QEMU snapshots:

• Zero overhead: ZFS snapshots have virtually no performance impact on the running VM
• No snapshot chains: Each ZFS snapshot is independent; deleting one does not affect others
• Block-level efficiency: Only changed blocks consume additional space
• Replication support: ZFS snapshots can be sent to other servers using zfs send

# Proxmox creates ZFS snapshots automatically when you use the GUI
# Manually, you can also work with them at the ZFS level
zfs list -t snapshot | grep vm-100

# Check space used by snapshots
zfs list -o name,used,refer -t snapshot

If you use ZFS storage, snapshots are significantly more efficient and flexible than QEMU file-based snapshots. This is one of the major reasons many Proxmox administrators choose ZFS as their primary storage backend.

Creating and Managing Snapshots

Creating Snapshots

You can create snapshots from the Proxmox web UI (VM > Snapshots > Take Snapshot), the command line, or remotely using tools like ProxmoxR on your mobile device.

# Create a snapshot via CLI
qm snapshot 100 pre-update --description "Before system update"

# For containers (LXC)
pct snapshot 200 pre-update --description "Before package upgrade"

Listing Snapshots

# List all snapshots for VM 100
qm listsnapshot 100

# Example output:
# `-> clean-install         2026-03-20 10:00:00  Fresh OS install
#    `-> pre-update          2026-03-25 14:30:00  Before system update
#       `-> current                                You are here!

The tree-like output shows the snapshot chain. Each snapshot depends on the ones before it in the chain, which is important to understand for deletion.

Reverting to a Snapshot

Rolling back restores the VM to the exact state captured by the snapshot. All changes made after the snapshot was taken are discarded.

# Rollback VM 100 to a specific snapshot
qm rollback 100 pre-update

# Rollback a container
pct rollback 200 pre-update

Rolling back a VM will discard all changes made since the snapshot. If you need to preserve current data, take another snapshot before rolling back, or use a backup instead.

Deleting Snapshots

# Delete a specific snapshot
qm delsnapshot 100 pre-update

# Delete a snapshot and all its children (force)
qm delsnapshot 100 clean-install --force

When you delete a QEMU snapshot, the overlay data is merged back into the base image. This can take time and generate significant I/O for large snapshots. Plan snapshot cleanup during low-usage periods.

Understanding Snapshot Chains

With QEMU file-based snapshots, each snapshot creates a new overlay that depends on the previous one. This forms a chain:

base-image.qcow2 → snap1 (overlay) → snap2 (overlay) → current (active)

This chain has important implications:

• Performance degradation: Each layer in the chain adds a small amount of read latency because QEMU must traverse the chain to find each block
• Deletion order matters: Deleting a middle snapshot requires merging its data, which is I/O intensive
• Long chains are risky: A corruption in any layer can affect all subsequent snapshots

Best practice: Keep snapshot chains short. Do not maintain more than 2-3 active snapshots at any time. If you need long-term retention, use backups instead.

Performance Impact of Snapshots

Snapshots are not free. Their performance impact varies by storage type:

• QEMU/qcow2 snapshots: Each active snapshot adds read latency (5-15% depending on chain depth). Write performance is minimally affected since writes go to the top overlay.
• ZFS snapshots: Negligible performance impact. ZFS handles copy-on-write at the block level with minimal overhead.
• LVM-Thin snapshots: Similar to ZFS, minimal overhead, but very long-lived snapshots with heavy writes can cause the thin pool to fill up.

Monitor your storage performance after creating snapshots. If you notice degradation, consider reducing the number of active snapshots or migrating to ZFS storage for more efficient snapshot handling.

Snapshots vs Backups: When to Use Each

This is one of the most common points of confusion for Proxmox administrators. Here is a clear breakdown:

Use snapshots when: You need a quick safety net before an update, configuration change, or software installation. Plan to revert or delete within hours or days.

Use backups when: You need long-term data protection, disaster recovery, or the ability to restore on different hardware. See our complete backup guide for details.

Snapshot Cleanup Best Practices

Forgotten snapshots are one of the most common causes of storage issues and performance degradation in Proxmox environments. Follow these practices:

1. Name snapshots descriptively: Use names like pre-kernel-update-6.1 rather than snap1
2. Set reminders to clean up: Delete snapshots once you confirm the change was successful
3. Audit regularly: Run qm listsnapshot across all VMs periodically to find forgotten snapshots
4. Monitor storage usage: Watch for unexpected storage growth caused by snapshot overhead
5. Limit chain depth: Never exceed 3 active QEMU snapshots per VM

# Quick audit: list all VMs with snapshots
for vmid in $(qm list | awk 'NR>1 {print $1}'); do
    snaps=$(qm listsnapshot $vmid 2>/dev/null | grep -v "current" | wc -l)
    if [ "$snaps" -gt 0 ]; then
        echo "VM $vmid has $snaps snapshot(s)"
    fi
done

Snapshots are a powerful tool when used correctly. Keep them short-lived, monitor their impact, and always pair them with a proper backup strategy. Combined with regular backups and monitoring through the Proxmox web UI or ProxmoxR, you will have a reliable safety net for every change you make to your infrastructure.