It is hard to imagine modern IT environments without snapshots. They are quick to create, can be automated, and ideally to restore very fast to an earlier state. So it is no surprise that in day-to-day operations you often hear the sentence:
“We have a snapshot — so we have a backup.”
But is that really true?
The short answer is: usually no.
The slightly longer answer:
A snapshot can be a very valuable recovery point. But only through independence from the production system, defined retention, copies to another medium, protection against manipulation, and reliable recoverability does it become a resilient backup concept.
So, what actually is a backup?
A backup is a separate, recoverable copy of production data, systems, or applications. Its purpose is to restore a defined state after data loss, corruption, user error, attacks, or infrastructure failures.
What matters is not only that data from an earlier point in time exists “somehow”. A backup should primarily fulfill the following characteristics:
- Independence from the production system
If the production storage, datastore, or volume breaks or is no longer reachable/readable, the backup must not be lost at the same time. - Recoverability
It must be possible to restore data at the required granularity: individual file, individual virtual disks, complete VM, multiple VMs, or entire applications. - Defined retention
Backups follow a configurable retention policy and are aligned with the company’s RPO and RTO requirements. - Protection against manipulation or deletion
Especially with regard to ransomware, immutability, air-gap concepts, or separate administrative security domains are crucial. - Copies in additional locations or on additional media
The classic 3-2-1 rule has often been extended in modern concepts to 3-2-1-1-0. At minimum: three copies, two different media, one external copy, one immutable/offline copy, and zero unverified restore errors.
A backup is therefore not just a “point in time”, but a deliberately protected and recoverable data set outside the immediate dependency of the production system.
What is a snapshot?
A snapshot is generally a point-in-time state of a system, a VM, a disk, a volume, or a datastore. It remembers what the data looked like at a specific point in time.
Technically, this is implemented differently depending on vendor and platform. Common methods include redirect-on-write, copy-on-write, delta disks, or redo log snapshot mechanisms.
Typical terms in this area include, for example:
- VM snapshot
- Disk snapshot
- Volume snapshot
- Datastore snapshot
- Storage array snapshot
- crash-consistentSnapshot
- application-consistent snapshot
- …
Depending on the technology and configuration, different objects can be restored from them:
- individual files
- individual virtual disks
- complete VMs
- complete datastore with multiple VMs
- application-consistent states
The key point, however, is this: many snapshots initially reside in the same storage or failure domain as the production data.
So if the medium on which the production data resides is damaged or lost, the local snapshot is often lost as well. This is exactly why, in many cases, a snapshot is not a backup, but a local recovery point. It can enable very fast recovery, but it also consumes capacity in the local storage area and does not automatically protect against the failure of that storage area.
Why a snapshot is often not a backup
A classic VMware VM snapshot is primarily intended to secure changes for a short period of time. Typical examples are:
- patch installation
- software update
- configuration change
- short-term rollback point
- consistency point for backup software
However, it is not intended to serve as a backup replacement over long periods of time. VMware/Broadcom recommends keeping individual snapshots for no longer than 72 hours. VMware also supports a maximum of 32 snapshots in a chain. Long snapshot chains can significantly negatively impact performance, stability, and consolidation times.
In practice, problems often do not arise from bad intentions, but from everyday situations: a snapshot is created “just to be safe”, is supposed to be deleted after one or two days — and is then forgotten. Or someone sees that a complete rollback works and incorrectly assumes that the data in the snapshot therefore exists like an independent backup copy.
The technical reason is simple: with classic VMware snapshots, changes are not written directly to the original virtual disk, but to delta files (which form a dependency chain) . The longer a snapshot exists and the more changes occur, the larger and more complex these delta structures become. When deleting or consolidating the snapshot, the changes must be merged back together. Depending on size, I/O load, and snapshot chain, this can take a long time. Read operations also become more complex because data must be read from multiple delta files.
A very recommended document that explains this in depth and covers all aspects of it is:
„VMware vSphere Snapshots: Performance and Best Practices„
So a snapshot is often more like a temporary seat belt — but not a replacement for fire extinguisher, vault, and emergency plan.
Is that always true? No.
There are important exceptions and gray areas.
Storage snapshots, for example on enterprise storage systems, often work differently from classic VM snapshots. Many modern storage systems create very efficient, metadata-based snapshots with minimal performance impact. Examples include NetApp ONTAP snapshots or other array-based technologies.
It becomes especially interesting when such snapshots are additionally replicated or copied to another system. A local storage snapshot on the same array protects against logical errors, accidental deletion, or short-term rollbacks. But if the entire storage system fails, this local snapshot is no longer available either.
However, if the snapshot is transferred to another storage system or another location using SnapMirror, SnapVault, replication, or comparable technology, it functionally approaches a backup or disaster recovery concept. Depending on the platform, such snapshots can also be manually mounted, cloned, or used for restores, even if the production storage is no longer available.
Nevertheless:
A snapshot alone is not automatically a backup. The architecture behind it is what matters.
And what about a Veeam Repository?
A Veeam Repository is fundamentally a storage target for backup files. Ideally, these backup files should reside outside the production datastore and therefore have no direct dependency on the storage of the production VM environment.
That is a central difference compared to many snapshots.
A Veeam backup is — with a clean repository design — an independent backup chain consisting of full backups and incrementals.
Different restore scenarios can be performed from it, for example:
- restore an individual file
- restore an individual virtual disk
- restore a complete VM
- Instant VM Recovery — meaning immediate VM startup from the backup, without the data first having to be copied/restored
- Application Item Recovery, for example for specific applications
- restore to other hosts or other storage systems
- bare-metal or agent-based recovery scenarios, depending on workload
- SureBackup
- malware and ransomware detection as well as automated recovery scenarios and test scenarios
- support for ransomware resilience, e.g. through immutability, secure restore points, and recovery workflows
- ….and a lot more
But the following is also important here:
A Veeam Repository is only truly independent and reliable if it has no critical physical or logical dependency on the protected workloads and the production infrastructure. Only then is a restore possible even in the event of a major outage.
If, for example, the repository exists as a virtual disk on the same storage as the production VMs, then a shared failure domain exists again. In a clean backup architecture, the repository should therefore be located on separate storage infrastructure — and ideally additionally protected by Backup Copy, offsite copy, Object Storage, tape, or an immutable repository.
Anyone who additionally creates at least one copy at another site or in another security area and takes immutability into account is significantly better prepared against hardware defects, accidental deletion, and ransomware.
Comparison: Snapshot vs. Backup Repository
The following table is intentionally simplified. Vendor implementations, versions, and configurations may differ.
| VMware Snapshot | Nutanix AHV Snapshot | vSAN (ESA) Snapshot | Netapp Snapshot* | Veeam Repository | |
| Tech | Delta Disk /Redo-Log Snapshot | Metadata-based /Redirect-on-Write | Native vSAN ESA Engine – Redirect-on-Write | WAFL / Ontap Snapshot – Redirect-on-Write | Image-level Backup: Full + Incremental |
| Based on | vDisk | vDisk | vDisk | Datastore | VM |
| Maximum Number | 32 | 35 | 200 | 1023 | Unlimited |
| Count Best Practice | 2-3 not more | As required but monitor capacity | As required but monitor capacity | ca. 1000 some for mirror or vault | Based on RPO/RTO |
| Duration Best Practice | not longer than 72h (3 days) | As long as needed Be aware of used Capacity | As long as needed Be aware of used Capacity | As long as needed Be aware of used Capacity | As long as needed |
| Size of Snapshot? | Small but can grow to same size as original | Changed Blocks + Metadata | Changed Blocks + Metadata | Changed Blocks + Metadata | Full + Deltas |
| Snapshot Deletion | Can take veeeeery long (Delta write back) | Fast (no delta write-back) | Fast (no data write-back) | Fast (no data write-back) | Retention Cleanup |
| Space reclaim? | Yes with consolidation | Yes with Garbage Collector Asynchr. | Yes with Garbage Collector Asynchr. | Yes with Garbage Collector Asynchr. | |
| Performance Costs | YES a lot | Almost None | 2% or less | None / negligible | Load on Source Depends on Method |
| Crash consistent | Yes | Yes | Yes | Yes | Yes |
| App. Consist. | with VMware Tools (VSS) | with Nutanix Guest Tools (VSS) | with VMware Tools (VSS) | with VMware Tools (VSS) | yes (with Tools) and scripts (Hot Backup Mode) |
| Backup | No | No — not alone; only local recovery point | No — not alone; only local recovery point | Almost but local only Copy with Mirror / Vault | Yes – This is a real backup |
| Restore to Point in time of Snapshot? | Yes | Yes | Yes | Yes | Yes – This is a real backup |
| File Restore inside VM | Not directly but with a Workarround | Not directly but with a Worarround | Not directly but with a Workarround | Yes with Backup Tool or Mounting by hand and copy the file | Yes – This is a real backup |
| Restore vDisk | No | No | No | Yes, because Datastore Level | Yes – This is a real backup |
| Restore if deleted from inventory | No | N/A | Yes with vSAN Data Protection | Yes | Yes |
| Restore whole VM | No | Yes (after deletion or Migration) No (after Datastore is broken) | No | Yes, because Datastore Level | Yes – This is a real backup |
| Restore with broken Datastore | No | No | No | No (default) but can be also Yes (with mirror / vault) | Yes – This is a real backup |
| Restore complete Datastore with 10+ VMs | No | No | No | Yes | Yes – This is a real backup |
| Function | Short Restore Point for changes inside the VM VDI Deployment Point in Time for Template Consistency for a Backup Software | Restore Point for changes inside the VM CBT + Consistency for a Backup Software | Short Restore Point for changes inside the VM New: Without performance impact VDI Deployment Point in Time for Template Consistency for a Backup Software | Local Point in Time for all VMs in Datastore | Full Backup on different Media |
*I chose NetApp because I know it very well. For more than 20 years, I have built NetApp systems, designed solutions, configured and troubleshot environments, written and developed best practices, and delivered trainings and workshops. Much of this also applies to other enterprise storage solutions, although the limits, configuration, and operational handling naturally differ.
Important points in detail
1. Performance
Not every snapshot has the same performance impact.
Classic VMware snapshots with delta disks have significant impact with a high change rate or deep snapshot chains. It becomes especially critical when snapshots remain in place for days or weeks and then have to be consolidated afterwards.
Modern snapshot methods, such as redirect-on-write, are built completely differently and are significantly more performant. Nevertheless: they also require storage space, metadata management, and proper monitoring.
With Veeam backups, the load typically occurs during the backup window: source, storage, network, proxy, and repository must read, transport, and write data. In return, however, the result is an independent backup copy.
2. Rolling back a VM
A snapshot is very powerful when you want to quickly roll back a VM after a change.
Example:
- patch installed
- application no longer starts
- rollback to snapshot
- VM runs again as before
This is an ideal snapshot safety-net scenario for planned changes/updates inside the VM.
But: if the VM files are corrupted, the datastore has been deleted, or the storage system fails, a local VM snapshot no longer helps. Then you need a backup on an independent medium.
3. Single File Recovery: Workaround vs. Mount vs. Wizard
With many snapshot technologies, restoring individual files is possible, but not always convenient.
Often you need manual work plus workarounds:
- clone VM
- mount snapshot
- manually attach virtual disk
- copy file from the file system
- then remove temporary VM or disk again
This works, but it is error-prone and costs time.
With Veeam, File-Level Recovery is a defined workflow. The backup is mounted, the file is searched for and restored — without having to restore the entire VM. This is a major difference in everyday operations, because many restore requests are not: “Please restore the whole VM”, but rather: “Can you get this one file from yesterday back for me inside the VM?”
4. Storage snapshots are valuable — but not automatically enough
Storage snapshots are extremely useful. They provide fast recovery points, often with very low impact. Especially with large amounts of data, they can be an important building block of a protection strategy.
But a local snapshot on the same storage does not protect against:
- storage failure
- site failure
- infrastructure failure, such as power outage, water damage, earthquake, fire damage, …
- certain ransomware scenarios
- administrative misconfiguration
- compromised credentials
- simultaneous deletion of production data and snapshots
Only through additional copies, replication, separate permissions, and immutability does a resilient protection concept emerge.
5. Storage snapshots as accelerators for backup and restore
Even though a local storage snapshot alone does not replace a complete backup, it can be a very valuable component of a modern backup strategy.
The major advantage is that backup solutions like Veeam can directly integrate virtualization and storage snapshots into the backup process. The VM is only briefly prepared for a consistent state, then the storage system creates a snapshot, and the actual backup is performed from this snapshot. As a result, the backup software does not have to read the data directly from the running production VM or from the active production state over a longer period of time.
This can bring several advantages:
- shorter load on the production VM
- lower impact on production storage
- shorter backup window
- better RPOs through more frequent backup runs
- less risk from long-open VM snapshots
- more efficient use of storage infrastructure
Veeam describes this method as Backup from Storage Snapshots. Storage snapshots are used to reduce the impact of backup and replication jobs on the production environment and to improve RPOs.
At the same time, storage snapshots can also help in the restore case. If a backup solution understands both the virtualization platform and the storage system, multiple recovery paths are available in a recovery scenario. Depending on the failure scenario, recovery can then be performed, for example, directly from a storage snapshot, from a replicated snapshot, or from a classic backup on the repository.
This can significantly improve recovery time, because large amounts of data do not always necessarily have to be written back from a backup repository. In the case of logical errors, accidental deletion, or short-term rollbacks, a storage snapshot may be the fastest path. In the case of storage failure, ransomware, or site loss, however, the independent backup on a separate repository or at another location is decisive.
You also should not forget that short-term VMware delta disk snapshots ensure that the VM is operating-system consistent or even application consistent, so that Veeam can back it up in that state. They are therefore a great tool for performing a backup — even if they are not the primary backup medium, but only a mechanism used during the process. For that purpose, however, they are excellent and are used by virtually all common backup vendors.
The combination is therefore particularly strong:
Snapshots provide fast local recovery points and/or consistency in VMs. Backups provide independent, long-term, and protected recoverability. Together they create a much more flexible recovery strategy.
Or put differently:
A snapshot does not replace the backup — but a good backup solution can use snapshots to significantly accelerate backup and restore processes and simplify operations.
This makes it clear: the question is not whether snapshots or backups are better. The real question is which technology is intended for which failure scenario — and how to combine both sensibly.
Conclusion
A snapshot is an excellent tool — but usually not a backup.
Snapshots are ideal for short-term rollbacks, fast recovery points, and as a technical foundation for consistent backups. They are fast, efficient, and integrated into many platforms.
A backup, however, goes further. It is independent of the production system, follows a retention policy, can be copied to other media or locations, and provides defined restore functions for different scenarios.
The most important question is therefore not:
“Do we have a snapshot?”
But rather:
“Can we restore if the production system, the datastore, or the site is no longer available?”
If the answer to that is “No”, then it is not a backup — it is only a local recovery point.
Sources / technical references
- VMware/Broadcom: Best Practices for VMware Snapshots
https://knowledge.broadcom.com/external/article/318825/best-practices-for-using-vmware-snapshot.html - VMware vSAN Data Protection
https://blogs.vmware.com/cloud-foundation/2024/08/02/superior-snapshots-using-vmware-vsan-data-protection/ - Nutanix Snapshots
https://portal.nutanix.com/page/documents/solutions/details?targetId=BP-2005-Data-Protection:nutanix-snapshots.html - NetApp ONTAP Snapshot Management
https://docs.netapp.com/us-en/ontap/data-protection/manage-local-snapshot-copies-concept.html - NetApp KB: ONTAP supports up to 1023 snapshots per volume
https://kb.netapp.com/on-prem/ontap/Ontap_OS/OS-KBs/Maximum_number_of_snapshots_supported_by_ONTAP - Veeam: 3-2-1 Backup Rule
https://www.veeam.com/blog/321-backup-rule.html - Veeam Help Center: Guest OS File Restore:
https://helpcenter.veeam.com/docs/vbr/userguide/guest_file_recovery.html - Veeam Help Center: Entire VM Restore:
https://helpcenter.veeam.com/docs/vbr/userguide/full_recovery.html - Veeam Help Center: Application-Aware Processing:
https://helpcenter.veeam.com/docs/vbr/userguide/application_aware_processing.html - Veeam Help Center: Hardened Repository and Immutability
https://helpcenter.veeam.com/docs/vbr/userguide/hardened_repository.html
