ONTAP Snapshot management

Local Snapshot copies make recovery fast because they preserve a point-in-time block map inside the volume. The operational work is choosing useful retention, monitoring changed-block growth, and restoring at the smallest safe scope.

What a local Snapshot is—and is not

A Snapshot is a recovery point, not an independent backup. It shares the volume and its failure domain. Replicate or export recovery data when the requirement includes aggregate, cluster, site, or administrative-fault survival.

Creating a Snapshot records the volume’s current file-system state without copying every block. Space grows later as active data diverges and older blocks remain referenced. A Snapshot’s displayed size therefore is not a file-by-file backup size, and deleting one copy may reclaim little when other copies still reference the same blocks.

Need	Preferred action	Blast radius
Recover one deleted file	Client-visible Snapshot directory or single-file restore workflow	File or directory
Test old data safely	FlexClone from a chosen Snapshot	Separate writable clone
Undo the whole volume	`volume snapshot restore`	Entire active volume
Survive loss of the source	SnapMirror or another independent backup	Separate destination

Inventory before changing anything

cluster::> volume show -vserver svm1 -volume data \
  -fields size,available,percent-used,percent-snapshot-space,snapshot-policy
cluster::> volume snapshot show -vserver svm1 -volume data
cluster::> volume snapshot show -vserver svm1 -volume data -instance
cluster::> volume snapshot policy show -vserver svm1
cluster::> volume snapshot autodelete show -vserver svm1 -volume data
cluster::> volume show-footprint -vserver svm1 -volume data

Record the policy, reserve, Snapshot owners, expiry or lock information, SnapMirror labels, available space, and current relationships. Owners can explain why a delete is refused. Do not bypass an owner until you understand which clone, replication baseline, application workflow, or restore operation depends on that copy.

Build and assign a Snapshot policy

This example uses an existing built-in schedule named hourly. Inspect schedules first; schedule names and required retention are site-specific.

cluster::> job schedule show
cluster::> volume snapshot policy create -vserver svm1 \
  -policy app-local -enabled true \
  -schedule1 hourly -count1 24 -prefix1 hourly \
  -snapmirror-label1 hourly

cluster::> volume snapshot policy show -vserver svm1 -policy app-local
cluster::> volume modify -vserver svm1 -volume data \
  -snapshot-policy app-local
cluster::> volume show -vserver svm1 -volume data -fields snapshot-policy

A policy can contain multiple schedule/count pairs. Use volume snapshot policy add-schedule to add another existing schedule. A SnapMirror label only makes a copy eligible for matching vault rules; it does not create or prove replication by itself.

Retention is a recovery design input: derive frequency and count from the required recovery points, workload change rate, capacity headroom, application consistency, and off-system protection—not from a universal “daily/weekly/monthly” recipe.

Create and verify a manual recovery point

For a crash-consistent copy, quiesce or coordinate the application when its recovery procedure requires it. ONTAP cannot infer application consistency merely from a Snapshot name.

cluster::> volume snapshot create -vserver svm1 -volume data \
  -snapshot pre_change_20260911 -comment "Before approved change CHG-1234"
cluster::> volume snapshot show -vserver svm1 -volume data \
  -snapshot pre_change_20260911 -instance

Use unique, automation-safe names and attach a ticket or purpose in the comment. If the copy must participate in a vault workflow, set a label deliberately and confirm the destination policy has a matching rule.

Choose the least-destructive recovery path

File or directory recovery

Start with a client-accessible Snapshot view or a supported single-file restore tool. Availability and path conventions differ by NAS protocol and configuration. Confirm permissions and application state before replacing live content.

Writable test or recovery clone

cluster::> volume clone create -vserver svm1 -flexclone data_recovery \
  -type RW -parent-volume data -parent-snapshot pre_change_20260911
cluster::> volume clone show -vserver svm1 -flexclone data_recovery

A FlexClone gives the selected point in time its own writable volume. It initially shares blocks with the parent, so deleting or splitting clones has capacity consequences that must be evaluated.

Whole-volume rollback

Destructive: volume snapshot restore replaces the active volume state and loses changes made after the selected Snapshot. Stop or coordinate clients, preserve evidence, validate SAN implications, and plan replication repair before proceeding.

# Read-only confirmation before the change
cluster::> volume snapshot show -vserver svm1 -volume data \
  -snapshot pre_change_20260911 -instance
cluster::> snapmirror show -source-vserver svm1 -source-volume data

# Run only inside an approved recovery procedure
cluster::> volume snapshot restore -vserver svm1 -volume data \
  -snapshot pre_change_20260911

Afterward, validate application data, protocol access, volume health, and every SnapMirror relationship. NetApp explicitly requires SnapMirror relationships to be updated after a volume Snapshot restore. Do not add -force merely to clear an error: it can invalidate newer replication reference copies.

Manage space without sacrificing recovery blindly

cluster::> volume snapshot show -vserver svm1 -volume data
cluster::> volume show -vserver svm1 -volume data \
  -fields size,available,percent-used,percent-snapshot-space
cluster::> volume snapshot autodelete show -vserver svm1 -volume data

The Snapshot reserve separates accounting inside the volume; it is not a hard cap on all Snapshot consumption. Active-file-system growth and retained changed blocks still compete for finite capacity. Correlate volume use with aggregate headroom, autosize, overwrite requirements, and protection policy before changing reserve or retention.

If the approved recovery design allows automatic deletion, configure conservative behavior and verify every field:

cluster::> volume snapshot autodelete modify -vserver svm1 -volume data \
  -enabled true -trigger snap_reserve -commitment try \
  -delete-order oldest_first
cluster::> volume snapshot autodelete show -vserver svm1 -volume data

-commitment try avoids deleting copies locked by another application. More aggressive commitment and destroy-list settings can disrupt clones or restore operations; their use needs a separate, tested decision. Autodelete applies only to read-write parent volumes.

Delete one confirmed-unneeded copy

cluster::> volume snapshot show -vserver svm1 -volume data \
  -snapshot pre_change_20260911 -instance
cluster::> volume snapshot delete -vserver svm1 -volume data \
  -snapshot pre_change_20260911

Deletion is irreversible and may reclaim less space than expected. If ONTAP reports an owner, stop and investigate; advanced -ignore-owners is not a routine cleanup switch.

Troubleshooting map

Symptom	Check	Likely direction
Scheduled copy missing	Policy enabled, assigned policy, schedule, EMS, volume state	Correct assignment or scheduling; confirm space
Delete refused	`volume snapshot show -instance`	Identify owner, lock, clone, or replication dependency
Space stays high after delete	Other Snapshots, clones, active data, footprint	Shared blocks are still referenced
Restore refused	Newer SnapMirror references, app tag, LUN/NVMe IDs	Repair the recovery plan; do not force casually
Snapshot is not application-consistent	Application quiesce and backup orchestration logs	Use SnapCenter or application-aware coordination

Primary sources and currency

Reviewed 11 September 2026 against current ONTAP 9 command documentation. Validate command availability and behavior on the exact ONTAP release, platform, protocol, and protection topology you operate.