Storage Snapshot

The Technoscoop snapshot reference describes the foundational concept: “Snapshot is a commonly used industry term (also called space-efficient copies) is an ability to capture or record the state of data at any given moment or point in time and preserve that snapshot as a guide to restore the data in case of a failure of the storage device. Typically, snapshot copy is done instantly and made available for use by other applications such as backup, UAT, reporting, and data replication.”¹

The fundamental concept

A storage snapshot is defined by what it captures and how it’s stored:

• What it captures: the logical state of a file system, volume, or VM at the exact moment of snapshot creation.
• How it’s stored: typically as metadata pointers to data blocks rather than a physical copy of all data.
• Where it lives: on the same storage system as the source data (this is the critical distinction from backup).
• Storage cost: proportional to changes since snapshot creation, not the full volume size.
• Creation speed: typically instant or near-instant; only metadata operations are required at creation time.
• Read access: snapshot data accessible like a normal file system or volume; reads do not affect source.

The “point-in-time” property

The point-in-time property is the central characteristic of snapshots:

• The snapshot represents the exact storage state at the instant of creation; subsequent changes to source data are not reflected in the snapshot.
• Multiple snapshots create a series of recovery points; reverting to any snapshot rolls back to that point in time.
• The original (active) data continues to evolve while the snapshot remains static.
• Some implementations support writeable snapshots that can be modified independently of the source; these are sometimes called clones.
• Read-only snapshots are the most common form and provide the strongest consistency guarantees.

Why snapshots are space-efficient

The Macrium VSS internal reference explains the efficiency property: “A snapshot only contains as much data as has changed since the snapshot started, you do not need an entire copy of your disk. Also, writes are only affected for used space, free space does not need to copy anything, as there is no original to preserve.”² The implications:

• A snapshot of an idle volume consumes minimal additional storage; no writes have occurred since creation.
• A snapshot of an active volume grows with the rate of changes; high write activity causes faster snapshot growth.
• Free space on the source volume is not part of the snapshot; only allocated blocks are tracked.
• Long-running snapshots on heavily-modified volumes can consume substantial storage as changes accumulate.
• Storage allocation is typically configurable: VSS uses 10% of volume by default; ZFS uses ARC; SAN arrays have configurable snapshot pools.

Snapshot lifecycle

Snapshots follow a typical lifecycle from creation to deletion:

• Creation: initiated by user, scheduler, or backup software; metadata operations only.
• Active period: snapshot is referenced for reads, rollbacks, or backup operations.
• Growth: as source data changes, snapshot storage grows to preserve original blocks.
• Quiescence: snapshot may remain idle for extended periods between use.
• Deletion or expiration: snapshot is removed when no longer needed; metadata cleanup releases storage.
• Persistence variant: some snapshots are temporary (deleted after use); others are persistent (retained for ongoing reference).

Common snapshot use cases

Snapshots address several specific operational requirements:

• Pre-update checkpoints: snapshot before applying OS or application updates; revert if update fails.
• Backup integration: create snapshot, then backup software reads from snapshot rather than live volume.
• Development and testing: create snapshot, make experimental changes, revert if needed.
• Quick recovery from accidental deletion: retrieve recently-deleted files from a recent snapshot.
• Reporting and analytics: run heavy queries against snapshot rather than affecting production performance.
• Replication source: snapshots provide consistent state for storage-level replication to remote sites.
• Cloning for cloning: writeable clones from snapshots provide development copies of production data.

Two fundamental mechanisms create storage snapshots: copy-on-write (CoW) and redirect-on-write (RoW). The choice has significant performance implications and determines how snapshots interact with the active volume.

Copy-on-Write (CoW)

The StorageSwiss snapshot reference describes copy-on-write: “Consider a copy-on-write system, which copies any blocks before they are overwritten with new information. In other words, if a block in a protected entity is to be modified, the system will copy that block to a separate snapshot area before it is overwritten with the new information. This approach requires three I/O operations for each write: one read and two writes. Prior to overwriting a block, its previous value must be read and then written to a different location, followed by the write of the new information.”³

The CoW write sequence:

1. Read original block: the block to be overwritten is read from its current location (1 read I/O).
2. Write to snapshot area: the original block is written to the snapshot storage (1 write I/O).
3. Write new data: the new data is written to the original location (1 write I/O).
4. Total cost: 3 I/O operations (1 read + 2 writes) per modification of a block tracked by the snapshot.

Redirect-on-Write (RoW)

The StorageSwiss reference describes the alternative: “If a block needs modification, the storage system merely redirects the pointer for that block to another block and writes the data there (i.e. it redirects on writes). The snapshot system knows where all of the blocks are that comprise a given snapshot; in other words, it has a list of pointers and knows the location of the blocks those pointers are referring to.”

The RoW write sequence:

1. Receive write request: new data destined for an existing logical block.
2. Allocate new physical block: a fresh block is selected from free space.
3. Write new data to fresh block: only one I/O operation needed (1 write I/O).
4. Update pointer: the logical-to-physical mapping is updated to reference the new block (metadata update).
5. Total cost: 1 I/O operation for the data write plus minimal metadata overhead.

CoW vs RoW comparison

Property	Copy-on-Write	Redirect-on-Write
I/O operations per write	3 (1 read + 2 writes)	1 (1 write)
Write performance impact	Significant (3x I/O)	Minimal (1x I/O)
Active volume layout	Stays contiguous over time	Becomes fragmented over time
Read performance over time	Consistent (data stays put)	Degrades with fragmentation
Snapshot deletion complexity	Simple (discard snapshot area)	Complex (reconcile redirected blocks)
Implementation complexity	Lower	Higher
Storage allocation pattern	Snapshot area separate from source	Snapshot and active share allocation
Common implementations	VSS, EMC TimeFinder/Snap, traditional arrays	NetApp WAFL, ZFS, Btrfs, modern arrays

The 200% I/O reduction

The Network World snapshot reference quantifies the RoW advantage: “Redirect-on-write snapshots can reduce I/O operations by 200% when modifying a protected block (one write versus two reads and one write), all while eliminating any additional computational overhead.”⁴ The performance impact:

• For write-heavy workloads, RoW can dramatically reduce snapshot overhead vs CoW.
• Database servers with high transaction rates benefit substantially from RoW snapshots.
• VDI environments where many VMs write simultaneously avoid CoW write storms.
• Backup operations using snapshots run faster on RoW because production volume is not slowed.
• Read-heavy workloads see less difference because both mechanisms preserve read paths.

RoW fragmentation trade-off

RoW eliminates the write penalty but introduces fragmentation. The Storage Gaga reference describes the issue: “However, as the life of the filesystem progresses, fragmentation and holes will cause the performance of the active filesystem to degrade. The reason is most related data blocks are no longer contiguous and the active file system will be busy seeking the scattered data blocks across the volume.”⁵ Implications:

• Active volume becomes fragmented as new writes scatter to different physical locations.
• Sequential read performance degrades over time as related data is no longer contiguous.
• SSDs largely mitigate this concern (no seek penalty); HDDs are significantly affected.
• Filesystems using RoW (ZFS, Btrfs) include defragmentation and rebalancing tools.
• NetApp WAFL includes optimization processes to maintain layout efficiency.

Snapshot deletion complexity

The TechTarget snapshot reference identifies a complexity in RoW: “There’s some complexity when a snapshot is deleted. The deleted snapshot’s data must be copied and made consistent back on the original volume.”⁶ The mechanics:

• CoW deletion: simply discard the snapshot area; no impact on active volume.
• RoW deletion: must reconcile redirected blocks back to original locations or update pointer trees.
• Performance impact: RoW deletion can take significant time and I/O for large snapshots.
• VM snapshot consolidation: VMware’s snapshot deletion (consolidation) is a common production concern that can take hours for large snapshots.
• Best practice: regularly clean up old snapshots to avoid accumulation; never let snapshots grow indefinitely.

Storage snapshots are implemented across a wide range of platforms and technologies. The following are the most-encountered implementations.

Microsoft Volume Shadow Copy Service (VSS)

The Wikipedia Shadow Copy reference describes Microsoft’s implementation: “Shadow Copy (also known as Volume Snapshot Service, Volume Shadow Copy Service or VSS) is a technology included in Microsoft Windows that can create backup copies or snapshots of computer files or volumes, even when they are in use. It is implemented as a Windows service called the Volume Shadow Copy service. Shadow Copy technology requires either the Windows NTFS or ReFS filesystems in order to create and store shadow copies.”⁷ VSS architecture:

• VSS writers: application-specific components that quiesce data for consistency; SQL Server, Exchange, Active Directory include VSS writers.
• VSS providers: components that create and maintain shadow copies; can be software (Microsoft default) or hardware (storage array integration).
• VSS requestors: backup applications that initiate snapshot creation through the VSS API.
• Timing constraint: VSS writers have 60 seconds to establish a backup-safe state before snapshot creation.
• Storage allocation: Windows reserves 10% of volume space for shadow copies by default.
• Volume size limit: VSS does not support volumes larger than 64 TB.
• Persistence: Windows Server 2003 added persistent snapshots; client Windows uses temporary snapshots.
• Management tools: vssadmin (command-line) and DiskShadow (Windows Server) for snapshot administration.
• Mechanism: built-in VSS provider uses copy-on-write; hardware providers may use RoW.

ZFS native snapshots

ZFS snapshots are deeply integrated with the file system and use redirect-on-write:

• Mechanism: ZFS uses copy-on-write at the filesystem level (technically RoW behavior); new writes always go to new blocks.
• Creation speed: instant; only metadata reference is created.
• Storage cost: initially zero; grows only as blocks change.
• Atomic transactions: all writes are atomic, snapshots are always consistent at the filesystem level.
• Snapshot syntax: zfs snapshot pool/dataset@snapshotname creates a snapshot.
• Rollback: zfs rollback pool/dataset@snapshotname reverts the dataset to snapshot state.
• Send/receive: ZFS snapshots can be replicated to remote ZFS pools via send/receive operations.
• Clones: writeable clones can be created from snapshots, providing branching dev/test environments.

Btrfs and APFS native snapshots

Linux Btrfs and macOS APFS provide similar copy-on-write snapshot capabilities:

• Btrfs snapshots: created via btrfs subvolume snapshot; subvolumes provide hierarchical snapshot organization.
• Btrfs send/receive: similar to ZFS for incremental replication.
• APFS snapshots: introduced with macOS High Sierra (2017); used by Time Machine for local snapshots.
• APFS automatic snapshots: macOS automatically creates local snapshots before macOS updates; provides system rollback.
• Time Machine local snapshots: hourly APFS snapshots when Time Machine is enabled, providing 24-hour rollback even without external backup destination.
• tmutil command: manage Time Machine snapshots from command line.

VMware vSphere VM snapshots

The DiskInternals VM snapshot reference describes VMware implementation: “In a VMware vSphere environment, VM snapshots are represented by a chain of .vmdk files that are dependent on one another.”⁸ The mechanism:

• Delta disk: when a snapshot is taken, VMware creates a delta disk file (.vmdk) that captures all subsequent writes.
• Original preserved: the base disk remains unchanged; new writes go only to the delta disk.
• Read path: VM reads must traverse all delta disks back to base to reconstruct current state.
• Snapshot tree: multiple snapshots create parent-child hierarchies; reverting branches the tree.
• Memory snapshots: when VM is powered on, snapshot can include memory state via .vmsn file.
• Consolidation: deleting a snapshot involves committing delta disk changes back to parent or base.
• Performance impact: longer snapshot chains add I/O penalty; VMware recommends snapshots be short-lived (less than 72 hours).
• Snapshot sprawl: long-running unconsolidated snapshots are a common VMware vSphere production problem.

Microsoft Hyper-V checkpoints

Hyper-V uses similar concepts under the “checkpoint” terminology:

• Checkpoint types: standard (crash-consistent) and production (application-consistent via VSS).
• AVHDX delta files: captures changes after checkpoint creation, similar to VMware delta disks.
• Checkpoint hierarchy: parent-child relationships for multiple checkpoints.
• Production checkpoints: introduced in Windows Server 2016, use VSS for application consistency inside Windows VMs.
• Standard checkpoints: faster but only crash-consistent; suitable for short-lived test scenarios.
• Management: Hyper-V Manager, PowerShell cmdlets (Checkpoint-VM, Restore-VMCheckpoint).

LVM snapshots (Linux)

Linux Logical Volume Manager (LVM) provides snapshot capability for non-CoW filesystems:

• Mechanism: traditional copy-on-write at the block level.
• Allocation: requires explicit storage allocation for the snapshot at creation.
• Snapshot syntax: lvcreate --snapshot --size 10G --name snap-name source-lv
• Limitation: if snapshot allocation fills, the snapshot becomes invalid.
• Use case: snapshot ext4, XFS, and other non-CoW Linux filesystems.
• Backup integration: common pattern is LVM snapshot + rsync/tar of snapshot data + delete snapshot.

Cloud platform snapshots

Major cloud platforms provide native snapshot capabilities for their persistent disk services:

• AWS EBS snapshots: stored in S3; incremental by default after first snapshot; cross-region copy supported; lifecycle policies for retention.
• Azure managed disk snapshots: point-in-time copies of managed disks; incremental snapshots in newer versions; cross-region copy via Azure Site Recovery.
• Google Persistent Disk snapshots: regional or multi-regional storage; automatic incremental; integrated with Cloud Backup and DR.
• Cross-region replication: all major clouds support snapshot replication for disaster recovery.
• Pricing: snapshots typically priced per GB-month with separate storage costs from source disks.

Enterprise SAN array snapshots

Enterprise storage arrays provide hardware-level snapshot capabilities:

• NetApp WAFL: redirect-on-write architecture; snapshots are zero-copy with metadata only; foundation of SnapMirror replication.
• Pure Storage: always-on snapshots with FlashRecover; SafeMode immutable snapshots for ransomware protection.
• Dell EMC PowerStore/Unity: redirect-on-write snapshots integrated with backup orchestration.
• HPE 3PAR/Primera: Virtual Copy snapshots with thin provisioning integration.
• IBM Spectrum Virtualize: FlashCopy with snapshot, clone, and continuous data protection variants.
• Pure SafeMode: immutable snapshots that cannot be deleted by administrators or attackers; ransomware-resistant.
• Hardware vs software providers: arrays integrate with Windows VSS via hardware providers for offload.

The most-important property of storage snapshots for data protection planning is what they do not protect against. Misunderstanding this distinction is one of the most-common causes of data loss in environments that thought they were protected.

The Veeam canonical guidance

The Veeam VMware snapshot reference provides the canonical statement: “While it is true that many Veeam products will use a snapshot as part of a backup, a snapshot by itself is not a backup. This logic applies to VMware VM snapshots, Hyper-V checkpoints and storage snapshots as well.”⁹ Veeam evangelist Rick Vanover’s framing: “We have nothing but evidence in the form of customer success stories that good arrays do indeed fail, so please take your backups onto different storage and follow the 3-2-1 Rule.”

The single point of failure problem

The HostAdvice snapshot reference identifies the central risk: “The most significant risk is a single point of failure. This is a significant disadvantage of VM snapshots. The snapshots are stored on a storage system. So, a failure of this system will destroy all snapshots and original data.”¹⁰ Specific failure scenarios:

• Storage controller failure: destroys access to both source and all snapshots simultaneously.
• Disk shelf failure: if disks are not protected by sufficient RAID, source and snapshots fail together.
• Filesystem corruption: ZFS, Btrfs, or APFS corruption affects snapshots stored within that filesystem.
• Ransomware on storage: ransomware that encrypts the volume affects both source and snapshots.
• Datacenter disasters: fire, flood, or theft destroying the storage system destroys all snapshots.
• Administrator error: accidentally deleting the volume or LUN destroys all snapshots within it.

Snapshots vs backups comparison

Property	Snapshot	Backup
Storage location	Same as source data	Different storage from source
Creation speed	Instant or near-instant	Minutes to hours
Storage cost	Proportional to changes	Proportional to data size
Drive failure protection	None	Yes
Ransomware protection	Limited (immutable variants only)	Yes (offline/immutable backups)
Disaster recovery	No (same site)	Yes (off-site backups)
Restoration speed	Instant (revert)	Minutes to hours
Retention period	Hours to weeks typical	Days to years
Compliance suitability	Generally insufficient	Yes for most frameworks

When snapshots are appropriate protection

Snapshots provide effective protection in specific scenarios:

• Accidental deletion recovery: retrieve files deleted hours or days ago from recent snapshots.
• Configuration mistake rollback: revert system after bad configuration change.
• Pre-update checkpoints: snapshot before applying updates; rollback if update causes problems.
• Test environment reset: snapshot baseline; test changes; revert for next test cycle.
• Database point-in-time recovery: combined with transaction logs for precise recovery to specific moments.
• Backup source: snapshot provides consistent state for backup software to read from.

When snapshots are insufficient

Several scenarios where snapshots cannot provide protection:

• Storage system failure: only off-system backups protect against this.
• Ransomware encrypting the storage: standard snapshots may be deleted or encrypted by attackers; only immutable variants protect.
• Site disasters: fire, flood, theft destroy all locally-stored snapshots.
• Long-term retention: snapshots typically retained for hours to weeks, not years.
• Compliance requirements: SEC 17a-4, HIPAA, SOX retention typically requires immutable off-system storage.
• Granular file restoration from old states: snapshots typically cover whole volumes; specific old files easier to retrieve from indexed backups.

The combined strategy

Effective data protection combines snapshots with backups for complementary coverage:

• Snapshots for rapid local rollback: hourly or daily snapshots for accidental deletion and configuration mistakes.
• Backups for disaster recovery: daily or hourly incremental or differential backups to separate storage.
• Off-site backups for disasters: at least one backup copy off-site per 3-2-1 rule.
• Immutable backups for ransomware: at least one backup copy that cannot be modified or deleted.
• Compliance archives: separate from operational backups; immutable WORM storage with retention policies.
• Snapshot replication for site DR: replicate snapshots to remote storage; combines snapshot speed with backup-like protection.

Snapshots provide specific recovery characteristics that differ from both backup recovery and direct drive recovery. Understanding these characteristics clarifies when snapshots are the appropriate recovery mechanism.

Standard snapshot recovery operations

Several recovery operations are possible from snapshots:

• Volume revert: entire volume rolled back to snapshot state; current changes lost.
• File restoration: specific files copied from snapshot to current volume; current state preserved otherwise.
• Mount and browse: snapshot mounted as separate volume; files accessed without modifying current state.
• Clone for testing: writeable clone created from snapshot; allows experimentation without affecting source.
• Database point-in-time recovery: snapshot combined with transaction logs to recover to specific moment.
• VM revert: entire VM reverted to snapshot state including disk and memory.

VSS shadow copies for previous versions

Windows VSS persistent snapshots provide the “Previous Versions” feature for accidental deletion recovery:

1. Right-click affected file or folder in Windows Explorer.
2. Select Properties, then Previous Versions tab.
3. List of available shadow copies displayed (created by scheduled VSS or System Restore).
4. Open a previous version to view it; copy specific files; or restore entire previous state.
5. Available on Windows Server with Shadow Copies for Shared Folders enabled, or via Backup and Restore on client Windows.
6. Storage limitation: maximum 64 shadow copies per volume; oldest are deleted as new ones are created.

VM snapshot revert workflow

Reverting a VM to a snapshot follows specific steps:

1. Identify target snapshot: choose the snapshot containing the desired state.
2. Power off VM (recommended): some hypervisors allow live revert but powered-off is safer.
3. Initiate revert: via vCenter, Hyper-V Manager, or hypervisor command line.
4. Hypervisor processes revert: delta disks above the target are removed or marked invalid.
5. VM resumes from snapshot state: as if the time between snapshot and now never occurred.
6. Subsequent changes lost: all writes after the snapshot are discarded; cannot be recovered without separate backup.
7. Application reconciliation: applications may need recovery procedures; databases may need transaction log replay.

ZFS snapshot recovery

ZFS snapshot recovery provides flexible options:

• Browse snapshot: ZFS snapshots accessible at .zfs/snapshot/ hidden directory; read files like normal.
• Copy individual files: standard cp command from snapshot directory to current location.
• Rollback dataset: zfs rollback pool/dataset@snapshotname reverts entire dataset; subsequent changes lost.
• Send to recovery: zfs send pool/dataset@snapshotname | zfs receive to remote pool for off-system recovery.
• Clone for non-destructive recovery: zfs clone creates writeable copy from snapshot; original snapshot preserved.

Snapshot recovery limitations

Specific scenarios where snapshot recovery fails:

• Snapshot deleted: oldest snapshots may have aged out of retention; gone permanently.
• Storage system unavailable: snapshot inaccessible if storage is offline.
• Snapshot corruption: rare but possible; same physical media as source means same corruption risks.
• Ransomware on snapshot storage: non-immutable snapshots may be encrypted or deleted by attackers.
• VM snapshot chain corruption: any delta disk in chain that is corrupted breaks recovery.
• Application inconsistency: crash-consistent snapshots may produce inconsistent application state.

When snapshots fail and recovery practitioners are needed

For data recovery professionals, snapshot failures point toward specific recovery approaches:

• Storage array failure: hardware-level recovery from underlying disks; snapshots cannot help.
• Filesystem corruption affecting snapshots: filesystem repair tools or specialized data recovery.
• VM disk file corruption: delta disk reconstruction; tools like StarWind V2V or specialized VMDK recovery.
• Encrypted volumes with snapshots: ransomware affects entire encrypted volume including snapshots; backup or off-system copy is the only recourse.
• Lost SAN snapshots: array-level recovery from underlying RAID; snapshots may not be recoverable.

Hash verification of snapshot data

For critical recovery operations from snapshots, hash verification confirms data integrity:

• Hash files restored from snapshot before relying on them.
• Compare against known-good hashes from backup logs where available.
• Filesystems with checksums (ZFS, Btrfs) provide automatic integrity verification at read time.
• For database recoveries, run database-level integrity checks after snapshot revert.
• VM snapshot reverts: validate guest filesystem and applications after revert.