Proxmox Backup vs Snapshot: Which One Actually Protects Your VMs?

Ask most Proxmox admins whether they have a backup strategy, and the answer is yes. Ask what happens when the underlying storage fails, and the answer usually involves snapshots, which aren’t backups. The distinction is not technical. In a real recovery event, the difference between a Proxmox snapshot and a Proxmox backup is the difference between restoring in minutes and explaining to leadership why the data is gone.

Snapshots are fast to create, visible in the Proxmox UI, and feel like protection. But they share the same storage pool as the VMs they’re protecting. When that storage fails due to a hardware fault, ransomware encryption, or accidental deletion, the snapshots get deleted with it. Every one of them, simultaneously.

This post breaks down exactly how Proxmox backup vs snapshot work, where each belongs in a real protection strategy, and why using snapshots as your primary recovery path leaves a gap most teams don’t discover until it’s too late. We’ll cover how each mechanism works, a direct attribute-by-attribute comparison, when each is the right tool, why snapshots fall short for disaster recovery, and how Zmanda Pro extends native Proxmox backup with incremental, encrypted, offsite-capable protection.

See how Zmanda Pro handles Proxmox VM backup

What is a Proxmox snapshot?

A Proxmox snapshot captures the entire state of a virtual machine at a single point in time: disk contents, RAM state (optionally), and VM configuration. The mechanism is copy-on-write (CoW): at the moment the snapshot is created, writes to the VM disk are redirected to a separate CoW layer rather than the base disk. The original disk state is frozen at the snapshot moment, while new changes accumulate separately.

Proxmox VE supports two snapshot types:

• Live snapshots with RAM state: Capture the complete running VM, including in-memory data. On rollback, the VM returns to exactly the state at the snapshot moment, with no cold boot and no service reinitialization from the guest’s perspective. These take slightly longer to create and use more storage due to the inclusion of RAM.
• Disk-only snapshots (no RAM): Faster to create, lower storage overhead. The VM resumes from a clean boot after rollback rather than resuming mid-run state. Appropriate for changes where the in-memory state doesn’t matter.

Snapshots are created via the Proxmox web UI or the pvesh CLI in seconds. That speed is operationally valuable for narrow use cases. But the critical constraint is fixed by the mechanism itself: snapshots are stored within the same storage pool as the VM they protect. On QCOW2-based local storage, snapshots are internal to the disk image. On Ceph, ZFS, or LVM-thin, they use the respective backend’s snapshot capabilities. In all cases, the snapshot does not leave the storage system the VM lives on. If that storage fails, all snapshots on it are lost.

What is a Proxmox backup?

A Proxmox backup creates a standalone, portable archive of a VM or container stored independently from its source. Proxmox VE’s native backup tool, vzdump, exports KVM VMs as compressed .vma archives or LXC containers as .tar.gz files. These archives can be written to any configured Proxmox storage target: NFS or CIFS shares, local disks, or a dedicated Proxmox Backup Server (PBS).

Three backup modes control the trade-off between consistency and guest availability:

• Snapshot mode: Backs up a running VM with minimal disruption. Requires the QEMU guest agent for application-consistent state. This is the standard production mode for workloads that cannot tolerate downtime.
• Suspend mode: Briefly pauses the VM to create a consistent backup, then resumes. Higher consistency than live backup, with a brief guest-unavailable window. Suitable for workloads where brief pauses are acceptable.
• Stop mode: Shuts down the VM for the duration of the backup. Maximum consistency. Requires a maintenance window but guarantees no in-flight transactions are captured mid-state.

Proxmox Backup Server (PBS), introduced in Proxmox VE 7, significantly advances native backup capability. PBS supports proxmox backup incremental transfers — after the initial full backup, only changed data blocks are transmitted. Combined with built-in deduplication, this substantially reduces both storage consumption and backup window duration. A PBS deployment with local or NAS storage is a major improvement over basic vzdump to a file share, and represents the intended path for production VM protection.

Third-party tools like Zmanda Pro extend this further: AES-256 client-side encryption, direct backup to cloud storage destinations (AWS S3, Azure Blob, Wasabi, Backblaze B2, and any S3-compatible endpoint), object lock for ransomware-immutable copies, and cross-platform restore that recovers a Proxmox VM directly into VMware or Hyper-V.

Proxmox backup vs snapshot: a head-to-head comparison

The differences between snapshots and backups map directly to which failure scenarios each mechanism can and cannot survive:

When snapshots make sense — and when they don’t

Snapshots have a legitimate role in a well-managed Proxmox environment. The use cases where they genuinely add value:

• Pre-change rollback points: Before a kernel update, package installation, or configuration change, a snapshot gives you an instant rollback if something goes wrong. The restore takes seconds, not the minutes required to recover from a backup archive. For routine change management, this is the right tool.
• Development and testing cycles: Spin up a VM, take a snapshot, run a destructive test or workload simulation, roll back to clean state. The speed of snapshot rollback makes this workflow practical in ways that backup-restore cycles are not.
• Short-term state capture: If you need to freeze a VM for an audit window, a brief migration, or an incident investigation, a snapshot works — provided the retention window is short and you accept the risk that this copy shares the same failure domain as the VM.

Where snapshots break down:

• Extended retention: Every active snapshot adds CoW overhead. On a high-write VM — a busy database server, a log-heavy application — a chain of 5+ snapshots can measurably degrade I/O performance as the CoW layer grows. Proxmox doesn’t enforce snapshot limits, which means this discipline falls entirely on the admin.
• Ransomware protection: Ransomware that targets storage encrypts everything accessible from that system — VM disks and snapshots alike. A snapshot stored on the same datastore as the VM provides no additional protection against a storage-level attack.
• Compliance requirements: SOC 2, HIPAA, and PCI DSS environments typically require demonstrably isolated, encrypted backup copies stored separately from production systems. Snapshots on production storage do not meet this standard, regardless of how many you keep.
• Cross-cluster or cross-platform DR: Proxmox snapshots are not portable across clusters and cannot be migrated to VMware or Hyper-V. If your DR plan involves restoring to alternate infrastructure — because the production Proxmox environment is unavailable — snapshots cannot support that scenario.

Why snapshots aren’t a disaster recovery strategy

The core problem with relying on snapshots for DR: they are not isolated from the infrastructure they are meant to protect.

A genuine disaster recovery strategy must account for the following failure modes:

• Storage hardware failure — the datastore and all its snapshots are gone
• Ransomware attack on production storage — snapshots are encrypted alongside VM data
• Datacenter event (fire, flood, power failure) — snapshots are lost with the hardware
• Accidental VM deletion — Proxmox deletes snapshots when the VM object is deleted

A backup stored on a separate system — with object lock enabled on a cloud destination — survives all four of these scenarios. A snapshot on the source datastore survives none of them.

For environments with ransomware protection requirements, Zmanda Pro’s AES-256 client-side encryption with a zero-knowledge architecture means backup data is unreadable even if an attacker accesses the storage bucket. Object lock support on AWS S3 and Wasabi (Governance and Compliance modes) creates copies that cannot be deleted or modified for the retention period — not by the application, not by administrators, and in Compliance mode, not by the storage provider itself. This is the protection layer that snapshots cannot provide.

The data path matters too. Zmanda Pro’s direct-to-storage architecture means backup data flows directly from the Proxmox host to the configured cloud destination — it never transits Zmanda’s infrastructure. There is no backup intermediary with access to your data between the Proxmox host and the S3 bucket.

How Zmanda Pro handles Proxmox VM backup

Zmanda Pro supports Proxmox VE with agentless snapshot-based VM backup. The Zmanda Pro client runs at the Proxmox host level and captures VM state via the Proxmox VE API — no agents are installed inside guest VMs. This means guest OS health has no bearing on backup operations, and VMs don’t require modifications to be protected.

Key capabilities for Proxmox environments:

• Forever incremental architecture: After the initial full backup, only changed data chunks are transferred on subsequent jobs. This supports <1-hour RPO on active workloads while keeping backup storage consumption and network utilization low on ongoing cycles.
• Chunk-based deduplication: Content Defined Chunking deduplicates backup data within Zmanda Pro’s Storage Vaults before transmission. In production deployments with similar-OS workloads, this reduces backup storage consumption by up to 90% compared to raw VM data size — a 10:1 ratio validated in the field.
• FIPS 140-2 compliant AES-256-CTR encryption with Poly1305 AEAD: Encryption happens entirely on the Proxmox host client. The key hierarchy is designed so that Zmanda’s servers cannot decrypt backup data — zero-knowledge architecture that applies even in SaaS deployment mode.
• Multi-destination storage flexibility: Back up directly to AWS S3, Azure Blob, Google Cloud Storage, Wasabi, Backblaze B2, local NAS, or any S3-compatible endpoint. No storage vendor lock-in — swap destinations without changing your backup architecture.
• Cross-platform restore: Restore Proxmox VMs to Proxmox VE, Hyper-V, or VMware vSphere. If the production Proxmox environment is unavailable in a disaster scenario, restore targets are not limited to Proxmox.
• Object lock support: AWS S3 and Wasabi Object Lock in Governance and Compliance modes creates ransomware-immutable copies. Even with valid storage credentials, locked objects cannot be deleted or modified before their retention period expires.

For teams running mixed hypervisor environments — Proxmox alongside VMware vSphere, Hyper-V, or physical servers — Zmanda Pro provides unified backup management across all workloads from a single console. That includes databases (MySQL, PostgreSQL, MS SQL Server, MongoDB), Microsoft 365, and Windows and Linux physical servers. See the full Zmanda Pro compatibility matrix for supported workloads.

The right approach: snapshots and backups working together

Snapshots and backups serve different time horizons and different failure scenarios. The answer isn’t to choose one — it’s to use each for what it’s actually designed for, and to make sure your backup layer covers the scenarios your snapshots cannot.

A practical layered strategy for Proxmox environments:

• Operational layer (snapshots): Take a snapshot before any change — patch, update, config edit. Set a per-VM snapshot limit appropriate to your storage capacity and CoW overhead tolerance. Delete snapshots once the change window closes cleanly. Do not accumulate snapshot chains as a substitute for retention policy.
• Backup layer (scheduled incremental backups): Run automated daily incremental backups via PBS or Zmanda Pro to a separate storage system. The forever-incremental architecture means daily cycles are storage-efficient even at scale.
• Offsite/cloud layer: Replicate backups to a cloud destination with object lock enabled. This is the layer that survives datacenter-level events. AWS S3 Compliance mode, Wasabi, or Zmanda Cloud Storage — matched to your compliance and cost requirements.
• Retention policy (automated): Define explicit retention rules and let the backup tool enforce them. Do not rely on manual snapshot management for long-term data protection.

This approach satisfies the 3-2-1 backup rule — three copies of data, on two different media types, one stored offsite. Snapshots on a single datastore cannot satisfy any of those three criteria on their own. Build the backup layer first, use snapshots as the operational supplement they were designed to be.

Proxmox snapshots are a useful operational tool. They are not a data protection strategy. If snapshots are your primary recovery mechanism — the thing you would reach for in a storage failure, a ransomware event, or a datacenter incident — you have a single point of failure that may not become apparent until the recovery moment arrives. Proxmox backup, whether through native PBS incremental architecture or a solution like Zmanda Pro, provides the isolation, portability, and encryption that actual disaster recovery coverage requires. The distinction between the two is not subtle in a real incident.