ONTAP Snapshots vs. VMware and Hyper-V Snapshots – Understanding the Difference

Although NetApp ONTAP, VMware vSphere, and Microsoft Hyper-V all use the term snapshot, the underlying mechanisms are fundamentally different.

VMware and Hyper-V use delta disks and dependency chains to preserve previous VM disk states, whereas ONTAP snapshots are point-in-time references to existing WAFL blocks.

When ONTAP reports a snapshot as 100 GB, this does not mean that a separate 100-GB snapshot file exists; it represents old WAFL blocks that must be retained because the snapshot still references them.

Since ONTAP snapshots operate at the WAFL block level, a basic understanding of block storage is helpful for understanding how snapshots work internally.

For an overview of block, file, and object storage and how these models relate to ONTAP, see my previous article here.

VMware / Hyper-V Snapshots

Each delta contains changes made since its immediate predecessor was frozen. You need the chain to reconstruct the state.

Base disk
   ↓
Delta 1 = writes after Snapshot 1
   ↓
Delta 2 = writes after Snapshot 2
   ↓
Delta 3 = writes after Snapshot 3

To reconstruct the VM state at Snapshot 3, VMware / Hyper-V needs the base disk and all preceding delta disks (Delta 1 → Delta 2 → Delta 3), because every delta contains only the changes made since its parent was frozen.

ONTAP Snapshots

It does not write every change into every snapshot. In fact, snapshots aren’t files receiving changes at all.

They are frozen references to WAFL blocks.

With ONTAP WAFL, a snapshot simply preserves references to the blocks that existed at that point in time. When data changes, WAFL writes the modified data to new blocks while the snapshot continues referencing the original blocks, so no delta-disk chain is required.

Snapshot 1 → blocks that existed at time 1
Snapshot 2 → blocks that existed at time 2
Snapshot 3 → blocks that existed at time 3
Active     → current blocks

Suppose block A changes:

Original:   A

Day 1 snapshot → A
Day 2 snapshot → A

A is changed → new block B

Day 1 snapshot → A
Day 2 snapshot → A
Active         → B

Then Snapshot 3 is created:

Day 1 snapshot → A
Day 2 snapshot → A
Day 3 snapshot → B
Active         → B

The snapshot itself needs almost no space, what consumes space are the old data blocks that ONTAP can no longer free because a snapshot still references them.

Example:

Before snapshot:

Active → A B C D

Take Snapshot 1:

Almost zero additional data space: both reference the same blocks.

Snapshot 1 → A B C D
Active     → A B C D

Now the application changes B to B2:

Normally ONTAP could eventually reclaim old block B. But it can’t, because Snapshot 1 still needs B to reproduce the filesystem as it looked when the snapshot was taken.

Snapshot 1 → A B  C D
Active     → A B2 C D

Change C as well:

Now B + C consume snapshot-related space, because they’re old blocks retained solely because of Snapshot 1.

Snapshot 1 → A B  C  D
Active     → A B2 C2 D

When ONTAP reports a snapshot as 100 GB, it does not mean that a separate 100-GB snapshot file exists; it represents old WAFL blocks retained because the snapshot still references them.

In contrast, with VMware or Hyper-V, a 100-GB snapshot/delta disk represents actual changes stored in a separate delta file as part of the snapshot chain.

Understanding Snapshot Size and Growth Patterns

Snapshot sizes do not necessarily increase with each successive snapshot in either architecture. Their size is primarily determined by the amount and type of data changes occurring over time.

With VMware and Hyper-V, the delta disk grows as new writes are redirected to it while that snapshot/checkpoint is active. With ONTAP, the reported snapshot size represents old WAFL blocks that must remain allocated because the snapshot still references them.

The important difference is therefore not the size pattern, but the underlying architecture: VMware and Hyper-V use dependent delta-disk chains, whereas ONTAP snapshots provide independent point-in-time views through WAFL block references.

Snapshot Dependency – ONTAP vs. VM Snapshot Chains

A fundamental difference between ONTAP and VMware/Hyper-V is snapshot dependency.

With VMware and Hyper-V, snapshots/checkpoints create delta disks that form a dependency chain. The required parts of this chain must remain intact to reconstruct the corresponding VM disk state, and delta disks cannot simply be removed from the middle of the chain without proper consolidation or merging.

ONTAP snapshots work differently. Each snapshot represents an independent point-in-time view of the filesystem through WAFL block references and does not depend on the preceding snapshot.

An individual snapshot can therefore be deleted without breaking newer or older snapshots; ONTAP simply reclaims blocks once they are no longer referenced by the active filesystem or any remaining snapshot.

WAFL Does Not Overwrite Existing Blocks

An important concept for understanding ONTAP snapshots is that WAFL does not overwrite an existing block when data changes. Instead, the modified data is written to a new block, and the active filesystem metadata is updated to reference that new block.

If a snapshot still references the original block, that block simply remains allocated and unchanged. It can only be reclaimed once neither the active filesystem nor any remaining snapshot references it.

This is what makes ONTAP snapshots possible without copying the entire dataset or maintaining a traditional snapshot delta chain.

Why Don’t VMware and Hyper-V Use the Same Snapshot Mechanism?

ONTAP snapshots are extremely fast because creating a snapshot is primarily a metadata operation. ONTAP controls the WAFL filesystem and its block allocation, allowing it to preserve a point-in-time state simply by maintaining references to existing blocks.

VMware and Hyper-V operate at a different layer. They provide virtual block devices such as VMDK and VHDX files to virtual machines but do not control the underlying storage filesystem and physical block allocation. Their native snapshot mechanisms must therefore work independently of the storage platform, which is achieved by redirecting new writes into delta disks.

When the underlying storage platform provides native snapshot capabilities, hypervisors can also integrate with and benefit from them. However, these are storage-level snapshots, rather than the native VM snapshot/checkpoint mechanism.

SnapMirror Cloud Backups – Why the Initial Backup Is Different

The situation is different when ONTAP snapshots are used for SnapMirror Cloud backups to Azure object storage. A local ONTAP snapshot can reference blocks that already exist on the volume, but Azure initially has none of those blocks.

The first backup therefore requires a baseline transfer, where the data blocks referenced by the snapshot are transferred to the object store. For example, if a volume contains approximately 10 TB of data, the initial backup represents essentially the complete protected dataset, subject to applicable storage efficiencies.

Subsequent backups use an incremental-forever approach and transfer only data blocks that have changed since the previous backup. The baseline and subsequent incremental data provide the blocks and metadata required to maintain the available recovery points.

This is an important distinction: creating the first local ONTAP snapshot does not create another 10-TB copy, whereas creating the first SnapMirror Cloud backup requires the protected dataset to actually be transferred to another storage system.

Links

Learn about ONTAP snapshot technology
https://docs.netapp.com/us-en/ontap/concepts/snapshot-copies-concept.html

Learn about managing the ONTAP snapshot reserve
https://docs.netapp.com/us-en/ontap/data-protection/manage-snapshot-copy-reserve-concept.html

Learn about managing the ONTAP snapshot reserve
https://docs.netapp.com/us-en/ontap/data-protection/manage-snapshot-copy-reserve-concept.html

Overview of virtual machine snapshots in vSphere
https://knowledge.broadcom.com/external/article/342618/overview-of-virtual-machine-snapshots-in.html

Hyper-V – Using checkpoints to revert virtual machines to a previous state
https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/checkpoints

Hyper-V storage I/O performance
https://learn.microsoft.com/en-us/windows-server/administration/performance-tuning/role/hyper-v-server/storage-io-performance

Learn about ONTAP SnapMirror Cloud backups to object storage
https://docs.netapp.com/us-en/ontap/concepts/snapmirror-cloud-backups-object-store-concept.html