ONTAP volume snapshot show: Space and Failures

2026年9月21日 LOG admin

Snapshot space accounting is the part of ONTAP administration that surprises people most often: a snapshot reports far more space in a report than the change rate suggests, snapshot creation starts failing with space errors, and deleting the obvious culprit does not release anything. The root causes are consistent and diagnosable. This article walks through the volume snapshot show output, the failure modes NetApp documents, and the delete sequence that avoids breaking SnapMirror relationships.

What volume snapshot show actually reports

cluster1::> volume snapshot show
cluster1::> volume snapshot show -vserver vs1 -volume vol_data -fields snapshot,total,used%,used
cluster1::> volume snapshot show -vserver vs1 -volume vol_data -detail

Key columns and what they mean for capacity planning:

Field	Meaning
`Total`	Total space referenced by the snapshot when it was taken (a reference, not consumption)
`Used%`	Percentage of the snapshot's referenced blocks that are uniquely held by this snapshot
`Used`	The actual disk space the snapshot holds down, which is what matters for aggregate growth
`Dependency`	Whether the snapshot is a reference for a SnapMirror or SnapVault relationship

Reading Total as consumption is the classic mistake: a 10 TB volume with hourly snapshots will show large totals while holding down a modest amount of unique data, because unchanged blocks are shared between the active file system and every snapshot.

How snapshots grow

Every write to an existing block forces ONTAP to keep the original block for the snapshots that reference it. So snapshot space grows with change rate, not with the size of the volume and not with the size of the data set. A volume with a 2 percent daily change rate and 24 hourly retentions holds down far more space than the same volume with a single daily snapshot, because the hourly snapshots preserve generations of blocks that the daily snapshot would have released.

cluster1::> volume snapshot show -vserver vs1 -volume vol_data -fields snapshot,used% -sort-by used%
cluster1::> volume show-space -vserver vs1 -volume vol_data -detail

volume show-space splits consumption into the active file system, snapshot reserve and other metadata. If snapshot consumption is approaching the snapshot reserve you will get space warnings before any user-visible problem — which is the point of setting the reserve at all.

Failures NetApp documents, and what they mean

Message	Cause	Action
`wafl.snap.create.skip.reason: skipping creation of <snap> snapshot (Snapshot already exists.)`	A snapshot with that name already exists — often from a policy and a manual creation colliding	Check the naming policies; remove the duplicate entry
Snapshot in dest volume is in use, cannot delete (`snapmirror.dst.snapDelErr`)	The snapshot is referenced by a SnapMirror relationship	Release the relationship reference first, then delete
"This Snapshot copy is currently used as a reference Snapshot copy by one or more SnapMirror relationships"	It is a common (base) snapshot for a mirror	Do not delete; either accept it or re-baseline the relationship
`raid.mirror.resync.snapcrtfail: could not create mirror resynchronization snapshot mirror_resync (No space left on device)`	SyncMirror cannot create its resync snapshot because the aggregate is full	Free aggregate space before the mirror degrades further

Safe deletion workflow

# 1. Identify candidate snapshots and confirm none are dependencies
cluster1::> volume snapshot show -vserver vs1 -volume vol_data -detail

# 2. Delete a single snapshot
cluster1::> volume snapshot delete -vserver vs1 -volume vol_data -snapshot snap_hourly_2026_09_20_00

# 3. Bulk delete an old generation, with confirmation
cluster1::> volume snapshot delete -vserver vs1 -volume vol_data -snapshot snap_hourly_2026_09_19*

Deleting snapshots is instantaneous from the operator's point of view, but it can take time for the freed space to appear in aggregate reports depending on how the blocks are referenced. Re-check with volume show-space after a few minutes rather than concluding the delete failed.

Preventing the next incident

Set a realistic snapshot reserve (5–10 percent for file workloads, more for high-change-rate databases) and alert at 80 percent of it.
Use a snapshot policy that varies by volume class: hourly for project data, daily for archive, none where the application already handles point-in-time copies.
Keep total snapshot consumption under a hard budget and monitor the trend, not just the current value.
Before any volume move or aggregate rebalance, verify snapshot counts and dependencies — they affect both the move time and the space required.
Never delete a snapshot purely to free space without checking the Dependency column first.

Quick diagnostics sequence

volume show-space -detail to see where consumption sits (AFS, snapshot, metadata).
volume snapshot show -sort-by used% to find the biggest holders.
volume snapshot show -detail to check dependencies before deleting.
Re-check aggregate free space with the aggregate space commands to confirm the trend.

Snapshot policies and schedules that scale

Snapshot space problems are almost always policy problems. Before adding storage, check whether the existing schedule is preserving more generations than the business actually needs.

Workload	Suggested policy	Rationale
Active project shares	Hourly, keep 24–48; daily, keep 7–14	Frequent restore points where users delete files
Databases with application-level backups	Daily, keep 3–7, or none	Application consistency beats snapshot granularity
Archive / read-mostly volumes	Weekly or monthly	Low change rate means low snapshot consumption
SnapMirror destinations	Policy driven by the relationship	Extra snapshots consume space and can block deletion
High-change-rate log volumes	Daily with short retention	Highest consumption per snapshot of any workload type

cluster1::> volume snapshot policy show -vserver vs1
cluster1::> volume snapshot policy modify -vserver vs1 -policy-name hourly -count 1 12
cluster1::> volume modify -vserver vs1 -volume vol_data -snapshot-policy hourly

Reducing hourly retention from 168 to 24 snapshots on a high-change volume can free more space than expanding the aggregate, and it removes nothing that anyone will miss.

Restoring from a snapshot

# Restore a single file with the built-in snapshot access
# From a client, browse the hidden snapshot directory (default .snapshot / ~snapshot)
ls ~/.snapshot/
cp ~/.snapshot/hourly.0/important.doc ./

# Restore a single file from the ONTAP CLI
cluster1::> volume snapshot restore-file -vserver vs1 -volume vol_data   -snapshot snap_hourly_2026_09_20_00 -path /qtree1/important.doc

# Restore an entire volume (destructive - current data is replaced)
cluster1::> volume snapshot restore -vserver vs1 -volume vol_data   -snapshot snap_daily_2026_09_19

Two warnings worth putting in front of anyone who runs these. A volume-level restore is destructive: data written after the snapshot is lost. And snapshots are read-only and deduplicated with the active file system, so a restore is a pointer operation rather than a copy — fast, but with no undo for what was overwritten. Where possible, restore individual files or clone the snapshot into a new volume, verify the content, then migrate.

# Safer alternative: clone the snapshot and inspect it
cluster1::> volume clone create -vserver vs1 -flexclone vol_data_clone   -type flexible-volume -parent-volume vol_data -parent-snapshot snap_daily_2026_09_19

Capacity alerting for snapshots

Alert when snapshot consumption crosses 80 percent of the snapshot reserve, not when the volume is full.
Track the growth rate; a sudden slope change usually means an application began rewriting data in place.
Set a hard limit on total snapshot consumption and treat exceeding it as an incident, not a warning.
Review the largest snapshots monthly and confirm each one has a justification.