NetApp ONTAP Snapshot Policy and Schedule CLI Setup

ONTAP snapshot copies are instantaneous, space-efficient point-in-time images, but they only protect your data if creation and retention are automated. That automation is a combination of two pieces: a snapshot policy, which defines when to create snapshots, how many to keep, and how to name them, and the job schedules (up to five per policy) that trigger the snapshots. The default policy already creates six hourly, two daily and two weekly snapshots, but production environments usually need their own cadence. This guide shows how to build custom schedules and snapshot policies from the ONTAP CLI and apply them to volumes.

There are two failure modes worth designing against from the start. The first is no snapshot at all, or a cadence too coarse for the recovery point objective the business actually needs - a nightly snapshot on a volume that hosts a database means up to a day of lost writes. The second is too many retained copies, which quietly consumes space and confuses operators during a restore because the useful image is buried among hundreds of others. A good policy is a deliberate answer to both.

Understanding ONTAP Snapshot Policies

A snapshot policy specifies when to create snapshots, how many copies to retain for each schedule, and how to name them - for example one snapshot every day at 00:10, keeping the two most recent copies, named daily.timestamp. A policy can contain up to five job schedules, each with its own count, prefix and optional SnapMirror label.

Policies are created in the context of an SVM, so a multi-tenant cluster can give each SVM its own retention philosophy. A policy is only a template; it does nothing until it is attached to a volume, and a single policy can be attached to many volumes. The relationship is what makes the model manageable: change the policy once and every volume that uses it inherits the new cadence and retention on its next scheduled run.

Policies are also independent of the schedules they reference. A job schedule answers the question when, a policy answers the questions how many and what to call it. That separation lets you reuse a single daily schedule across dozens of policies with different retention counts, or attach the same policy to a hundred volumes without duplicating the timing definition.

Snapshots Are Cheap, But Not Free

Snapshot copies themselves consume almost no space at creation time because they reference existing blocks rather than copying them. Space is consumed later, when the active file system changes a block that a snapshot still references; that block must be preserved for the snapshot, so the volume's used space grows. This is why a volume with an aggressive snapshot policy and heavy write workload can consume far more space than the raw size of its data suggests.

Retention count is therefore a space decision as much as a data protection decision. Keeping a hundred hourly snapshots on a high-churn volume can preserve a large amount of changed data, and deleting old snapshots is the fastest way to reclaim space in a pinch. The df and volume show -fields snapshot-* commands exist precisely to make this accounting visible.

Step 1: Create a Job Schedule

Job schedules are cron-style definitions created with job schedule cron create. Month, day-of-week and hour accept all to run on every value:

cluster1::> job schedule cron create -name mydaily -hour 0 -minute 10
cluster1::> job schedule cron create -name myweekly -dayofweek "Saturday" -hour 3 -minute 0
cluster1::> job schedule cron create -name myweeklymulti -dayofweek "Monday,Wednesday,Sunday" -hour 3,9,12 -minute 0,20,50

The name of a job schedule is a cluster-wide object with its own namespace, so choose a naming convention early - for example prod_hourly, prod_daily, dr_15min. The all keyword is accepted for month, dayofweek, day, hour and minute, and multiple values are comma-separated. A schedule with -dayofweek saturday -hour 3 runs once a week, while leaving -dayofweek all and setting -hour 0 -minute 10 runs once a day.

Verify what you created before you build a policy on top of it, because a typo in a day name produces an error at creation time, and an unintended combination produces a schedule that silently never fires the way you expect:

cluster1::> job schedule cron show -name myweeklymulti

Step 2: Create the Snapshot Policy

cluster1::> volume snapshot policy create -vserver svm1 -policy snap_policy_daily -schedule1 mydaily -count1 5 -prefix1 daily -snapmirror-label1 daily

The example creates a policy named snap_policy_daily that runs the mydaily schedule, keeps five snapshots named daily.timestamp, and tags them with the SnapMirror label daily so a SnapMirror relationship can select exactly these copies for replication. Add up to five schedule/count/prefix groups on one policy:

cluster1::> volume snapshot policy create -vserver svm1 -policy prod_hourly_daily -schedule1 hourly -count1 6 -prefix1 hourly -schedule2 daily -count2 7 -prefix2 daily -enabled true

Each numbered group is independent: schedule1/count1/prefix1, schedule2/count2/prefix2 and so on up to five. The -enabled true argument sets the policy state, and a policy can be created disabled and enabled later. Runs from different groups interleave in the same snapshot list, distinguished by their prefixes, which is why a clear prefix convention pays off during a restore.

Prefixes must be alphanumeric and are used as the leading part of the snapshot name, so a prefix such as hourly produces names like hourly.2026-09-14_0305. Choosing prefixes that map one-to-one onto schedules makes it trivial to see at a glance which retention bucket a given snapshot belongs to.

Step 3: Apply the Policy to a Volume

cluster1::> volume snapshot policy modify -vserver svm1 -volume vol1 -policy snap_policy_daily
cluster1::> volume show -vserver svm1 -volume vol1 -fields snapshot-policy

The volume snapshot policy modify command attaches, changes or removes the policy on an existing volume; the same result can be achieved with volume modify -snapshot-policy. The change takes effect immediately for future scheduled runs and does not require the volume to be taken offline or remounted, which means you can tune retention on a live production volume without a maintenance window.

Attaching a different policy does not delete snapshots created under the previous policy. Existing copies remain until they age out of the new retention counts or are deleted manually, so a policy cutover produces a period during which old and new snapshots coexist. Plan for that overlap when estimating space.

Snapshot Autodelete and Space Protection

When a volume fills up, ONTAP can either stop writes or start deleting old snapshots. That behaviour is governed by the snapshot autodelete policy, and getting it right is the difference between a volume that protects its data and a volume that protects its availability:

cluster1::> volume snapshot autodelete modify -vserver svm1 -volume vol1 -enabled true -trigger volume -target-free-space 20 -delete-order oldest_first -commitment try

Setting -trigger volume means autodelete starts when the volume crosses its threshold, and -target-free-space 20 asks ONTAP to keep freeing snapshots until twenty percent of the volume is free again. The -commitment value controls how aggressively snapshots that are part of a replicated relationship are treated: try prefers deleting snapshots that are not committed to a mirror, while destroy will delete even those.

Autodelete is a safety valve, not a substitute for correct sizing. A volume that runs autodelete constantly is a volume that is undersized or over-snapshotted, and the symptom is a snapshot list that never matches the configured retention because the oldest copies keep disappearing sooner than the policy intends.

Snapshot Reserve and Space Accounting

Each volume has a snapshot reserve, expressed as a percentage of the volume, that snapshot copies are expected to consume. The reserve affects how the volume reports available space to clients:

cluster1::> volume modify -vserver svm1 -volume vol1 -percent-snapshot-space 5
cluster1::> volume show -vserver svm1 -volume vol1 -fields percent-snapshot-space,space-used,space-available,space-total

With a snapshot reserve of five percent, clients see the volume as slightly smaller than its physical size, and snapshot growth up to that percentage does not reduce the space visible to NFS or SMB clients. Fractional reserve, which historically guaranteed enough space to overwrite every block a snapshot referenced, is disabled by default in modern ONTAP releases; the practical consequence is that the earliest warnings of a snapshot-driven space problem now come from the volume's used space rather than from a reserve accounting field.

Restoring Data from a Snapshot

There are three ways to recover, and choosing correctly matters. The most surgical is to copy a single file or directory out of the snapshot through the NFS or SMB client path - clients reach snapshots through a hidden directory, and users can restore their own files without administrator involvement. The second is an in-place restore of the whole volume:

cluster1::> volume snapshot restore -vserver svm1 -volume vol1 -snapshot snap_policy_daily.2026-09-14_0010

An in-place restore replaces the active file system with the contents of the snapshot and is destructive to any changes made since the snapshot; it also requires a period of downtime for the volume and disrupts existing snapshots and SnapMirror relationships, so it should be treated as a last resort. The third option, and the safest for non-destructive recovery, is to clone the snapshot into a new flexible volume and mount the clone for inspection, then copy the needed data out.

SnapMirror Labels and Replication

The -snapmirror-label argument on a policy schedule group tags the snapshots it creates so a SnapMirror policy can select them for replication. A typical arrangement labels hourly snapshots hourly, nightly ones daily and weekend ones weekly, and the mirroring relationship is configured to replicate whichever label matches the required recovery point objective. Without labels, a mirror relationship has no mechanism to distinguish a routine hourly copy from a nightly baseline, and it will simply take the latest snapshot it finds.

Because labels tie snapshots to replication, changing a prefix or a label on a live policy can interrupt a mirror relationship's ability to select new snapshots until the matching SnapMirror policy is updated on both sides. Plan label changes together with replication changes rather than treating them as independent storage chores.

Verifying Schedules, Policies and Snapshots

cluster1::> job schedule cron show
cluster1::> volume snapshot policy show -vserver svm1
cluster1::> volume snapshot show -vserver svm1 -volume vol1

The snapshot list should grow at the scheduled times with the configured prefixes; the oldest copies are deleted automatically when the retention count is exceeded. To confirm the policy is actually attached and what it will do next, inspect the volume's policy details and the job history:

cluster1::> volume snapshot policy show -vserver svm1 -policy snap_policy_daily -instance
cluster1::> job show -name "Snapshot copy*"
cluster1::> job history show -job-name "Snapshot copy of volume vol1"

Managing and Deleting Snapshots

Individual snapshots can be removed by name or in bulk by policy, and both are routine operations when reclaiming space:

cluster1::> volume snapshot delete -vserver svm1 -volume vol1 -snapshot daily.2026-09-01_0010
cluster1::> volume snapshot delete -vserver svm1 -volume vol1 -snapshot-policy snap_policy_daily

Deleting snapshots is safe for the active file system but removes your ability to recover to those points in time, so it should be a deliberate decision rather than a reflexive response to a space alert. When the goal is purely to reclaim space, check first whether autodelete is already doing the job and whether the volume is simply undersized relative to its retention requirements.

Best Practices

Give each workload class its own policy so that a database and an archive volume are not forced into the same cadence. Keep prefixes and SnapMirror labels aligned so automation can select snapshots reliably. Size volumes for retention, not only for active data. Enable autodelete with a target free-space threshold rather than letting a full volume stop writes. Test a restore from a snapshot periodically, because an untested recovery procedure is an assumption rather than a capability. Finally, document which policy applies to which volume, since the person restoring data during an incident is rarely the person who created the policy.

Frequently Asked Questions

How many snapshots can a volume hold? ONTAP supports a very large number of snapshots per volume, but the practical limit is space and manageability rather than a hard count. Hundreds of retained copies on a high-churn volume will consume meaningful capacity.

Does changing a policy delete existing snapshots? No. Existing snapshots remain until they exceed the new retention counts, are superseded by newer copies in the same group, or are deleted manually.

Can I apply a policy to multiple volumes at once? Yes. A policy is a template, and attaching it to many volumes either individually or through a bulk operation gives them a consistent cadence without duplicating definitions.

What happens if a volume fills up with snapshots? With autodelete enabled ONTAP begins removing snapshots according to the configured order and commitment; with it disabled the volume can reach a state where writes fail.

Related articles: NetApp ONTAP SnapMirror configuration, NetApp ONTAP CLI cheat sheet, and ONTAP NFS export policy configuration. See also the broader ONTAP SnapMirror setup and troubleshooting guide, ZFS send and receive snapshot replication for a comparison of snapshot mechanics, and ONTAP EMS event log filtering to monitor snapshot and space events.

原文链接：https://docs.netapp.com/us-en/ontap/data-protection/create-snapshot-policy-task.html