Understanding Snapshots – NetApp ONTAP vs. VMware, Hyper-V, and Cloud Disk Snapshots

The term snapshot is widely used across storage systems, hypervisors, and cloud platforms, but the underlying technology can be fundamentally different.

A NetApp ONTAP snapshot based on WAFL block references works very differently from a VMware snapshot or Hyper-V checkpoint using delta/differencing disks, and cloud disk snapshots in Azure, AWS, and GCP introduce yet another approach.

In this article, we will look under the hood at these different snapshot technologies, how changed data is handled, what dependencies exist between snapshots and the original data, and why understanding these differences is important for backup, recovery, storage consumption, and performance.

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.

How Traditional Filesystems Handle Data Blocks

Before looking at ONTAP snapshots, it is useful to understand how conventional filesystems organize and modify data. Filesystems such as FAT, NTFS, ext3, and ext4 divide storage into blocks or clusters and maintain metadata that maps files and directories to these physical storage locations.

When an existing file is modified, these traditional filesystems generally update the corresponding data blocks in place where possible. The previous contents of those blocks are therefore no longer preserved simply because the file was changed.

File: example.txt

Before modification:

Filesystem metadata
       │
       ├── Block A
       ├── Block B
       └── Block C

Modify data stored in Block B

After modification:

Filesystem metadata
       │
       ├── Block A
       ├── Block B'   ← updated/overwritten data
       └── Block C

Old contents of Block B are not automatically preserved.

Journaling filesystems such as NTFS, ext3, and ext4 additionally maintain a journal to help preserve filesystem consistency after crashes or interrupted writes. However, journaling should not be confused with snapshot or Copy-on-Write technology, the journal does not normally preserve previous versions of all file data.

Copy-on-Write Filesystems – Btrfs Is Different

Btrfs behaves differently because it is a Copy-on-Write (CoW) filesystem. Instead of overwriting an existing data block, modified data is written to a new location and the filesystem metadata is updated to reference the new block.

Before modification:

Metadata ──────► Block A

Modify Block A

                  ┌──► Block A     ← old data
Metadata ─────────┤
                  └──► Block B     ← new data

This makes Btrfs conceptually much closer to NetApp WAFL than traditional filesystems such as NTFS or ext4.

Snapshots can continue referencing the old blocks while the active filesystem references the newly written blocks.

ext4 can use CoW-like mechanisms in specific contexts/features, and NTFS has other higher-level snapshot technologies such as VSS, but neither makes the normal filesystem itself a CoW filesystem like Btrfs.

This Copy-on-Write concept brings us to NetApp WAFL, where writing modified data to new blocks and preserving references to existing blocks is fundamental to how ONTAP snapshots can provide efficient point-in-time filesystem views.

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.

FabricPool Tiering – What Does “Tiering Snapshot Data” Actually Mean?

When ONTAP uses FabricPool, terms such as “tiering snapshots” or “snapshot data tiering” can be misleading if we imagine a snapshot as a separate file or copy of the volume.

As described earlier, an ONTAP snapshot primarily consists of metadata and references to WAFL blocks. Therefore, FabricPool does not take a snapshot file and move it to the capacity tier. Instead, it moves the actual cold data blocks referenced by the snapshot from the performance tier to the capacity tier.

For example:

Before tiering:

Snapshot 1 ─┐
Snapshot 2 ─┼──→ Block A ──→ Performance Tier
Snapshot 3 ─┘

Active FS ─────→ Block B ──→ Performance Tier

If Block A is no longer referenced by the active filesystem but is still required by one or more snapshots, FabricPool can move the block’s data to the capacity tier:

After tiering:

Snapshot 1 ─┐
Snapshot 2 ─┼──→ Block A ──→ Capacity Tier (Object Storage e.g. Azure Storage Account Blob Storage)
Snapshot 3 ─┘

Active FS ─────→ Block B ──→ Performance Tier

The snapshots continue to reference exactly the same logical WAFL block. Only the physical location of the block’s data has changed. As long as at least one snapshot or the active filesystem references that block, ONTAP must retain it regardless of which tier contains it.

Snapshot retention determines whether and how long a WAFL block must continue to exist. FabricPool determines where the data for that block is physically stored.

With the snapshot-only tiering policy, ONTAP tiers cold blocks that are no longer associated with the active filesystem and are retained by snapshots. With the auto policy, cold user-data blocks from both snapshots and the active filesystem can be tiered after the configured minimum cooling period.

ACLs, directory structures, and filesystem metadata remain on the local performance tier.

Source: https://docs.netapp.com/us-en/ontap/fabricpool/tiering-policies-concept.html

In my previous article below, I covered FabricPool in detail, including how cold WAFL blocks are moved from the local performance tier to an object-storage capacity tier such as Azure Blob Storage.

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.

Cloud Disk Snapshots – Azure, AWS, and GCP

Hyperscaler disk snapshots introduce another snapshot architecture. Unlike VMware and Hyper-V snapshots, cloud disk snapshots are independent of the original virtual disk from the user’s perspective and can remain available even after the source disk has been deleted.

Azure, AWS, and GCP typically store these snapshots incrementally: the initial snapshot represents a complete 1:1 point-in-time copy of the source disk, while subsequent snapshots store changed blocks. Any internal dependencies between recovery points are managed transparently by the cloud provider, allowing each snapshot to be treated as an independent point-in-time recovery source.

The key difference becomes clear when looking at the dependency on the original virtual disk.

VMware and Hyper-V maintain a dependent disk chain, whereas hyperscaler snapshots are managed as separate recovery objects and remain usable independently of the source disk.

VMware / Hyper-V

Base virtual disk
      ↓
   Delta 1
      ↓
   Delta 2
      ↓
   Delta 3

The running VM/snapshot chain depends on
the original virtual disk and its delta chain.

Azure / AWS / GCP

Source Virtual Disk
       │
       └──── Snapshot System
                 │
        ┌────────┼────────┐
     Snapshot 1  Δ2       Δ3
        full    changes  changes

Source disk can be deleted.
Snapshots remain usable.

Cloud disk snapshots already provide disk-level backup and recovery, while services such as Azure Backup, AWS Backup, and Google Backup and DR add higher-level functionality such as scheduling, retention, consistency, vault storage, and centralized management.

Underneath, these services still rely heavily on snapshot and incremental block technologies.

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

ONTAP FabricPool volume tiering policies
https://docs.netapp.com/us-en/ontap/fabricpool/tiering-policies-concept.html

Azure managed disks overview
https://learn.microsoft.com/en-us/azure/virtual-machines/managed-disks-overview

Amazon EBS snapshots
https://docs.aws.amazon.com/ebs/latest/userguide/ebs-snapshots.html

About archive and standard disk snapshots
https://docs.cloud.google.com/compute/docs/disks/snapshots