Backup & DR

A Snapshot Is Not a Backup: Differences and Real Risks

The most dangerous misconception in infrastructure: "we have snapshots, we are protected." Discover why this belief could cost you all your data.

business EasyDataHost calendar_today March 14, 2026 schedule 8 min read

In virtualisation environments, one of the most common and most dangerous misconceptions is believing that a snapshot is equivalent to a backup. The phrase "don't worry, we have snapshots" is repeated in IT departments around the world, and it is one of the leading causes of irrecoverable data loss when things truly go wrong.

The reality is straightforward: a snapshot and a backup are fundamentally different mechanisms, designed for different purposes, with incomparable levels of protection. Confusing them is like confusing a seatbelt with a life insurance policy: both protect you, but against entirely different threats. In this article we take an in-depth look at what each one is, when to use each tool, the risks of relying exclusively on snapshots and how to design a robust protection strategy combining both approaches with solutions such as Veeam Cloud Connect.

What Is a Snapshot

A snapshot is a point-in-time image of the state of a virtual machine or storage volume at a specific moment. It is not a full copy of the data, but rather a mechanism that freezes the current state and begins recording only the changes that occur from that point onwards.

Most hypervisors such as Proxmox VE, VMware vSphere and Hyper-V implement snapshots using a technique called copy-on-write (COW). When a snapshot is created, the original virtual disk is marked as read-only and a new delta file (also called a delta disk or differencing disk) is generated to store all subsequent writes. The result is a chain: base disk + delta 1 + delta 2, and so on.

Key characteristics of a snapshot:

  • Instantaneous: created in seconds without interrupting the running VM.
  • Dependent: the snapshot does not exist independently; it requires the original base disk to function.
  • Delta disk: stores only the changes since the capture moment, not a full copy.
  • Same storage: resides on the same storage system as the original VM.
  • Temporary: designed for short-term use (hours or a few days), not for long-term retention.

In Proxmox VE, for example, a QEMU snapshot captures the disk state (and optionally RAM) as a reference point. In VMware, -delta.vmdk files are created that chain the changes together. The concept is identical in both: data is not duplicated, differences are recorded.

What Is a Backup

A backup is an independent, complete copy of the data, stored on a separate system from the original. Unlike a snapshot, a backup is portable: it can be moved to another server, another data centre or even the cloud. It does not depend on the source storage to function and can be restored even if the original hardware has been completely destroyed.

Professional backup solutions such as Veeam Backup & Replication produce copies that include all the information needed to rebuild a VM from scratch: virtual disks, hardware configuration, metadata and, optionally, memory state. These copies are stored in dedicated repositories, which can be local (NAS, backup server) or offsite via services like Veeam Cloud Connect or Object Storage S3.

A professional backup offers capabilities that a snapshot simply cannot provide: long-term retention with granular policies (keep dailies for 30 days, weeklies for 12 weeks, monthlies for 12 months), granular restore of individual files or databases, automatic integrity verification and the ability to restore to different hardware than the original. Furthermore, modern backups support immutability, which prevents even an attacker with administrator credentials from encrypting or deleting them.

Comparison Table: Snapshot vs Backup

The following table summarises the fundamental differences every systems administrator should know:

Feature Snapshot Backup
Independence No: depends on the original base disk Yes: autonomous, self-contained copy
Portability No: tied to the original storage Yes: restorable on any hardware
Retention Hours to a few days (max 24-72h) Days, weeks, months or years
Performance impact Degrades I/O over time None after copy completes
Ransomware protection None: accessible from the same storage High: offsite and immutable
Disaster recovery No: if storage fails, everything is lost Yes: full restore from scratch
Restore granularity All or nothing (entire VM) VM, disk, file, DB, object

Why Snapshots Fail as a Backup

Using snapshots as your primary data protection strategy is a mistake that comes with a heavy price. The reasons are multiple and all of them critical:

  • warning They depend on the original storage: if the disk array, RAID controller or storage node fails, the VM and all its snapshots are lost simultaneously. There is no external copy.
  • warning They degrade performance: each snapshot adds a layer of indirection to read and write operations. The more active snapshots, the higher the I/O latency. Under intensive workloads (databases, mail servers), the impact can be devastating.
  • warning They do not protect against ransomware: an attacker who compromises the hypervisor or storage has direct access to the snapshots. They can encrypt or delete them just as easily as the production disks.
  • warning They are not portable: you cannot take a Proxmox snapshot and restore it on a VMware server, nor send it to an alternative data centre. They are bound to the hypervisor and storage where they were created.

The Danger of Accumulating Snapshots

One of the most frequent problems in production environments is the uncontrolled accumulation of snapshots. What starts as a "temporary" snapshot before an update ends up becoming a chain of five, ten or even twenty deltas accumulated over weeks or months. Each forgotten snapshot grows silently as the VM continues to operate.

The consequences are severe:

  • error Fragile delta chain: the longer the chain, the greater the risk of corruption. A single damaged sector in an intermediate delta can render the entire VM inaccessible.
  • error Failed consolidation: when attempting to delete or merge old snapshots, the consolidation process can fail if the storage lacks sufficient space or the chain is too long, leaving the VM in an inconsistent state.
  • error Disk space exhaustion: deltas grow without limit. A VM with a 500 GB disk can have snapshots occupying 1 TB or more, filling the datastore and causing all VMs hosted on it to crash.
  • error Inaccessible VM: in extreme cases, corruption of the snapshot chain prevents the VM from booting at all. Without an independent backup, recovery may be impossible.

According to official documentation from Veeam and major hypervisor vendors, snapshots should never be kept active for more than 24 to 72 hours under any circumstances. The recommendation is unanimous: snapshots are temporary tools, not data protection strategies.

When TO Use Snapshots

With all the above said, snapshots are an extraordinarily useful tool when used correctly. Their strength lies in immediacy and the ability to provide a rapid short-term rollback point:

  • check_circle Before an update or patch: take a snapshot before applying an OS patch, application update or critical configuration change. If something goes wrong, you can revert the VM to its previous state in seconds.
  • check_circle Testing environments: in development and QA environments, snapshots enable reproducible starting points for testing. Create the snapshot, run the tests and revert to the clean state.
  • check_circle Short-term rollback: if you need an immediate return point during a maintenance window, the snapshot is perfect. The key is to always remove it within 24-72 hours.

The golden rule is simple: use snapshots as a temporary safety net, never as your permanent protection strategy. They should always exist within the context of a broader backup plan.

The Right Strategy: Snapshot + Backup

The optimal combination leverages the best of both worlds. Snapshots provide an ultra-short RPO (Recovery Point Objective) for immediate rollbacks, while backups guarantee real protection against disasters, ransomware and hardware failures.

A well-designed protection architecture with Veeam Backup & Replication works as follows:

  • looks_one Daily local backup: Veeam creates an incremental backup of each VM every night to a local repository. This provides rapid restore for day-to-day operational incidents.
  • looks_two Immutable offsite backup: an additional copy is automatically sent to an external repository via Veeam Cloud Connect or to Object Storage S3 with immutability enabled. This copy is inaccessible to any attacker who compromises the on-premise infrastructure.
  • looks_3 DRaaS for business continuity: for critical workloads, Veeam DRaaS replicates VMs to a secondary data centre, enabling failover in minutes with minute-level RPO and RTO.
  • looks_4 Snapshots only for maintenance: snapshots are reserved exclusively for planned maintenance windows (updates, patches) and are always removed within a maximum of 24-72 hours.

This architecture follows the 3-2-1 principle: three copies of the data, on two different media types, with one copy offsite. Snapshots do not count as one of those copies; they are simply an additional operational tool. For environments requiring maximum protection, our Enterprise Cloud service includes native Veeam integration and CEPH storage with triple replication.

Checklist: Snapshot vs Backup

Verify that your protection strategy meets these critical requirements:

  • check_circle No snapshot remains active for more than 72 hours in production environments.
  • check_circle An independent backup exists for every critical VM, stored in a repository separate from production storage.
  • check_circle At least one backup copy is offsite and immutable, beyond the reach of an attacker who compromises the local infrastructure.
  • check_circle Periodic restore tests are performed to verify that backups are functional and complete.
  • check_circle Monitoring and alerts are in place for orphaned snapshots or snapshots exceeding the permitted time threshold.

Conclusion

A snapshot is a fast and valuable operational tool, but it is not a backup and never will be. Relying exclusively on snapshots for data protection means accepting a risk that can result in the total, irrecoverable loss of critical information. Snapshots do not survive a storage failure, they do not protect against ransomware and they degrade performance when they accumulate.

The right strategy combines snapshots for immediate short-term rollbacks with professional, offsite and immutable backups for real protection. Implementing this combination with Veeam Backup & Replication, Cloud Connect and Object Storage S3 is a straightforward process that the EasyDataHost team can help you design and deploy.

  • arrow_right Snapshots are not backups: they depend on the original storage and do not protect against hardware failure or ransomware.
  • arrow_right Accumulating snapshots degrades performance and can cause corruption and VM inaccessibility.
  • arrow_right Use snapshots only for short-term maintenance (maximum 24-72 hours) and always remove them afterwards.
  • arrow_right Implement offsite and immutable backups as your true line of defence against disasters.
Snapshot Backup Virtualisation Veeam Proxmox
photo_camera

Stop relying solely on snapshots

The EasyDataHost team helps you implement a real backup strategy with Veeam Cloud Connect, immutable S3 Object Storage and DRaaS in our Tier III+ data centre in Madrid.