Storage Admin Hub
All guides/Data Protection
Data Protection · Worked procedure

Set up Snapshot-based recovery

Policy, retention, capacity, and file-level restore.

By Hrishikesh NaikUpdated 4 min read
Scope

AFF/FAS volume Snapshots · file recovery pilot; application-consistent backup is separate

Scenario

Example: hourly recovery points retained for one day and daily points retained for a week. Set the actual policy from business RPO and available snapshot space.

About the command and output examples

Names, addresses and results are illustrative. Commands have not been executed against a live storage system or SAN switch for this publication. Confirm syntax and compatibility for your release, then rehearse in an approved lab. Existing-data recovery and destructive changes need an environment-specific plan. Read the editorial standards.

01Set the recovery objective

  1. Agree maximum tolerable data loss (RPO) with the application owner. Check whether crash-consistent storage snapshots are sufficient or application quiescing is required.
  2. Choose a snapshot schedule and retention that fit the RPO and expected change rate. Check available aggregate capacity and define a separate off-cluster protection copy.
Read-only checks 
volume show -fields snapshot-policy
volume snapshot show
volume show-space

02Configure and test

  1. Assign the approved snapshot policy to the volume in System Manager. Confirm snapshots appear on schedule and retention behaves as expected.
  2. Create a disposable test file on an authorized client, take a recovery point if needed, change the file, then restore that single file from the chosen snapshot into a safe test location. Compare content and permissions.
  3. Record restore time and steps in the runbook. Do not treat an in-place snapshot on the same cluster as a site disaster recovery copy.
Acceptance check

A named recovery point exists; test file restores with correct content and access.

03Respond to space pressure

  1. Inspect snapshot consumption, active data and aggregate headroom separately. Determine which snapshot is required by SnapMirror or retention before changing policies.
  2. Never delete a snapshot solely because the volume is full without checking replication dependency and recovery commitments.
Read-only investigation 
volume snapshot show
volume show-space
snapmirror show

04Worked retention policy and its limits

A retention count says how many scheduled points are kept; it does not promise that every point will be restorable for an application or that the data survives loss of the source cluster. A file share can often use a storage-consistent point directly. A database requires its supported application backup, flush or log recovery design.

Planning choices for an illustrative file workload
Example requirementExample policy choiceValidation
Recent accidental edits24 hourly pointsCheck the last completed hourly points.
Prior-day file recovery7 daily pointsRestore a sample from an older day.
Cluster lossSeparate off-cluster protectionDemonstrate recovery from the destination.
  1. Verify the hourly and daily job schedules exist on your cluster and occur at suitable times. Avoid changing shared schedules for one volume.
  2. Create a dedicated Snapshot policy, attach it to a disposable lab volume and inspect the resulting association. Count1/count2 are schedule retention counts, not hours or days by themselves.
  3. Monitor changed-block consumption through at least a representative workload cycle. A snapshot initially shares blocks; retained changes determine continuing consumption.
Example policy change on an approved test volume 
job schedule cron show
volume snapshot policy create -vserver svm_prod -policy snap_projects -schedule1 hourly -count1 24 -schedule2 daily -count2 7
volume modify -vserver svm_prod -volume vol_projects -snapshot-policy snap_projects
volume snapshot policy show -vserver svm_prod -policy snap_projects
volume show -vserver svm_prod -volume vol_projects -fields snapshot-policy

05A file recovery drill with an observable result

  1. Create a disposable file with known content and record its checksum. Create a named test snapshot, then change or remove only that disposable file.
  2. Restore the old file to a separate approved recovery path using the supported Snapshot browse or single-file recovery workflow. Leave the live production path untouched during the first test.
  3. Compare content/checksum and permissions. Have the owner confirm the required file is recovered before planning an in-place replacement. Record recovery time and the point used.
Example lab Snapshot creation and read-only inventory 
volume snapshot create -vserver svm_prod -volume vol_projects -snapshot recovery_lab_01
volume snapshot show -vserver svm_prod -volume vol_projects
Acceptance check

A file from the selected point is restored to a separate path and passes content and access validation.

06When a retention change needs additional review

If daily points are missing, compare the policy association, schedule and successfully created snapshots before changing retention. If space pressure grows, inspect the workload’s changed blocks, clones and replication dependencies. Removing one snapshot may not free its displayed size because blocks can remain referenced elsewhere. Keep required recovery points while selecting an approved capacity response.

  1. Capture current policy and actual recovery points before a change.
  2. Verify the off-cluster policy’s snapshot labels and retention if it relies on local points.
  3. After changing an approved policy, inspect the next scheduled cycle and repeat the recovery drill; a saved configuration is not recovery evidence.
Continue learning

Use the section links to revisit a step, or follow a related guide below.

Official references and further reading

Choose the matching release in the vendor documentation before using a command or design. References open on the publisher’s website; linked material remains with its publisher.