A question came up during a recent customer demo of Veeam I was hosting == Is a snapshot enough for a backup or do you need an actual backup. My answer was you should have both. In this post, we'll break down exactly what snapshots and backups are, where each excels, where each fails, and how Veeam ties them together into a strategy that actually protects you.
Some will say snapshots are good enough. Others will say they're a disaster waiting to happen. The truth, as usual, is somewhere in between — but with an important nuance: "snapshots and backups are not the same thing, and you need both."
Misunderstanding the difference between these two technologies has led to real data loss events at real organizations.
What is a Snapshot?
A snapshot is a "point-in-time capture of a storage state". It records the state of a VM, volume, or dataset at a specific moment — not by copying all the data, but by tracking *what has changed* since the snapshot was taken.
Most snapshots work using one of two mechanisms:
- Copy-on-Write (COW): The original data blocks are copied to a separate area before being overwritten. The snapshot points to the original blocks.
- Redirect-on-Write (ROW): New writes go to a new location; the snapshot continues to point to the original blocks.
Either way, the result is the same: a fast, space-efficient way to preserve a point-in-time view of your data.
Where Snapshots Live
- Hypervisor-level:** VMware vSphere snapshots, Hyper-V checkpoints
- Storage array-level:** NetApp, Pure Storage, HPE Nimble, Dell EMC snapshot features
- Cloud-level:** AWS EBS snapshots, Azure VM snapshots, GCP persistent disk snapshots
- Application-level:** SQL Server database snapshots
What Snapshots Are Great For
- Speed — Created in seconds, regardless of data size
- Quick rollback — Undo a bad patch or config change in minutes
- Pre-change safety net — Snapshot before every update, patch, or deployment
- Low initial storage overhead — Only changed blocks consume additional space
- Consistent application state — VSS-integrated snapshots capture a consistent app state
What is a Backup?
A backup is a full, independent copy of your data stored in a separate location. Unlike a snapshot, a backup does not depend on the source storage system to be intact, healthy, or even operational.
Backups typically involve:
- Copying data to a dedicated backup repository (disk, tape, cloud)
- Retention policies that keep multiple historical versions
- Deduplication and compression to manage storage efficiently
- Encryption for security in transit and at rest
Where Backups Live
- Dedicated backup appliances or servers
- Network-attached storage (NAS)
- Object storage (S3, Azure Blob, GCS)
- Tape libraries
- Cloud repositories (Veeam Cloud Connect, native cloud backup)
What Backups Are Great For
- Independence — Completely separate from production storage
- Long retention — Keep years of historical data affordably
- Ransomware protection — Immutable backups can't be encrypted or deleted
- Granular recovery — Restore individual files, emails, VMs, or databases
- Portability — Restore to different hardware, different site, or different cloud
- Compliance — Meet regulatory requirements for data retention
The Critical Differences
| Feature | Snapshot | Backup |
| Storage dependency | Tied to source storage | Fully independent |
| Creation speed | Seconds | Minutes to hours |
| Retention | Short-term (hours to days) | Long-term (months to years) |
| Recovery granularity | Entire volume/VM | File, VM, app object |
| Ransomware protection | Vulnerable if storage is compromised | Immutable options available |
| Offsite copy | Rarely | Standard practice |
| Storage efficiency over time | Degrades (snapshot chains grow) | Stable with dedup/compression |
| Independent of production failure | No | Yes |
Why Snapshots Alone Will Eventually Fail You
Snapshots are powerful, but relying on them as your only protection is a gamble you will eventually lose.
Problem 1: Snapshot Chains Break
Snapshots are not independent copies — they're deltas that depend on a chain of blocks going back to the base. If any link in that chain is corrupted or the base disk fails, every snapshot built on top of it is worthless.
Problem 2: They Live on the Same Storage
If your storage array fails, gets hit by ransomware, or is physically destroyed in a fire, your snapshots go with it. They are not protected against storage-level failures.
Problem 3: They Grow — and Degrade Performance
The longer a snapshot exists, the more changed data it tracks. Long-lived snapshots consume significant storage and can noticeably impact the performance of production VMs. This is why most best practices recommend keeping hypervisor snapshots for no more than 24–72 hours.
Problem 4: They Don't Meet Compliance Requirements
Most regulatory frameworks (HIPAA, PCI-DSS, GDPR, SOX) require data retention over extended periods. A 72-hour snapshot window doesn't satisfy a 7-year retention requirement.
Problem 5: Limited Granular Recovery
Need to restore a single email from three weeks ago? A deleted file from a specific folder? A specific table from your database? Snapshots typically give you all-or-nothing recovery — you roll the entire volume back. Backups give you surgical precision.
Why Backups Alone Aren't Enough Either
Before backup-only advocates get too comfortable — backups have their own weaknesses:
Backup Windows Create RPO Gaps
If you run nightly backups, you could lose up to 24 hours of data. For many workloads, that's unacceptable. Snapshots can dramatically reduce your RPO by capturing state every 15–60 minutes throughout the day.
Restores Take Time
Restoring a large VM from backup, especially from an offsite or cloud repository, can take hours. When a developer accidentally deletes a critical file and needs it back in five minutes, a snapshot is the right tool for that job.
Backups Don't Help with Quick Operational Rollbacks
You patched a server and it broke something. Reverting from a snapshot takes two minutes. Restoring from a backup takes much longer and potentially involves downtime. Use the right tool for the right job.
How Veeam Brings Both Together
This is where Veeam really shines. Rather than treating snapshots and backups as competing technologies, Veeam uses them as complementary layers in a unified data protection strategy.
How Veeam Uses Snapshots Internally
When Veeam runs a backup job, it doesn't just copy files. It:
1. Triggers a hypervisor snapshot (VMware vSphere or Hyper-V checkpoint) to get a consistent, point-in-time state of the VM
2. Reads the data from the snapshot — not from the live VM — minimizing production impact
3. Processes and transfers the data to your backup repository with deduplication and compression
4. Deletes the temporary snapshot once the backup is complete
This means your Veeam backups are already snapshot-consistent. You get the consistency benefits of snapshots baked into every backup job.
Storage Snapshot Integration
If you have a supported storage array (NetApp, HPE, Dell EMC, Pure Storage, and many others), Veeam can integrate directly with your array's snapshot technology:
- Veeam Explorer for Storage Snapshots — Browse and restore directly from storage array snapshots through the Veeam console
- Storage snapshot orchestration — Veeam can trigger and manage array-level snapshots as part of its backup workflow
- Backup from Storage Snapshots — Use array snapshots as the source for Veeam backups, reducing load on production VMs even further
The Right Strategy: Layered Protection
Here's how to think about combining snapshots and backups in a practical architecture:
Layer 1 — Hypervisor Snapshots (Operational Safety Net)
Purpose: Quick rollback before changes, short-term safety net
Retention: 24–72 hours maximum
Use case: Pre-patch snapshot, quick "oops" recovery
Layer 2 — Veeam Backup to Local Repository (Operational Backups)
Purpose: Fast restores, granular recovery, recent history
Retention: 14–30 days
Use case: File-level restore, VM recovery, accidental deletion
Layer 3 — Veeam Backup Copy to Immutable Repository (Protection Backups)
Purpose: Ransomware protection, disaster recovery
Retention: 30–90 days
Use case: Ransomware recovery, site disaster, storage failure
Layer 4 — Veeam Backup Copy to Offsite/Cloud (Long-Term Retention)
Purpose: Compliance, long-term archive, geographic redundancy
Retention: 1–7 years (GFS policy)
Use case: Compliance audit, long-term data recovery, DR from total site loss
Layer 5 — CDP (for Tier 0/1 Workloads)
Purpose: Near-zero RPO for mission-critical VMs
Retention: Seconds to minutes of journal history
Use case: Databases, ERP systems, anything where minutes of data loss is too much
Final Thoughts
Snapshots and backups are not rivals — they're teammates. Snapshots give you "speed and agility" for operational recovery. Backups give you "resilience and independence" for serious protection. Together, they cover each other's weaknesses.
Veeam is built around this philosophy. Every backup job uses snapshots for consistency. Storage array integration extends that to your hardware. CDP closes the RPO gap for your most critical workloads. And immutable repositories ensure that even when everything else goes wrong, your backups remain untouchable.
The question isn't "snapshots or backups?" It's "do I have the right combination of both?"
Review your environment today. Find the gaps. Fill them — before a ransomware attack or a failed storage array does it for you.
