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

Restore a file, volume, or replicated copy

Choose the smallest safe recovery scope and test the result.

By Hrishikesh NaikUpdated 3 min read
Scope

Recovery scope selection · file, application or volume restore

Scenario

Example: a user deleted /projects/budget.xlsx at 10:15. A 10:00 snapshot exists. Restore only the file when possible; a volume rollback would revert unrelated work.

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.

01Identify the target

  1. Confirm SVM, volume, path, deletion time, latest good recovery point, and whether the file belongs to a running database or VM. Ask the owner to stop writes to the affected object if needed.
  2. List snapshots and check a readable copy exists. If the local snapshot is missing, check the SnapMirror destination or external backup and its retention.
Read-only investigation 
volume snapshot show
snapmirror show
volume show

02Select recovery scope

  1. For an individual NAS file, use a file-level snapshot restore or copy the older version to an alternate path first; compare content, ownership, and ACLs before replacement.
  2. For a complete volume rollback, document every change since the chosen snapshot and coordinate an application outage. Follow the version-specific restore procedure and confirm no incompatible protection operation is in progress.
  3. For a SnapMirror backup, restore from a selected destination snapshot to a separate recovery volume when a safe test is needed.
Acceptance check

Recovery point, destination path, expected overwrite scope, and approver are recorded.

03Verify and protect

  1. Have the application owner validate the recovered object and permissions. Check logs for subsequent errors.
  2. Take a fresh recovery point after the service is consistent and ensure replication resumes. Document actual recovery time (RTO) and data age (RPO).
Acceptance check

Recovered data is usable; protection resumed; unintended files are unchanged.

04Worked decision: choose a separate recovery target first

Illustrative case: a file was deleted at 10:20, while other users have valid changes after 10:20. Rolling the entire volume back to 10:00 would also affect those changes. Recovering the one file from 10:00 to an alternate location lets its owner verify it before an approved replacement. The time saved by a broad rollback can be outweighed by unrelated data loss.

Use the narrowest scope that meets the recovery objective
RequestPreferred initial testWhy
One spreadsheet deletedRecover that file to an alternate folderOther users’ later changes remain untouched.
Database corruptionApplication-supported recovery to an isolated instanceStorage consistency alone may not meet application requirements.
Whole volume compromisedIsolated recovery volume/clone from an accepted pointValidate the point before reconnecting writers.
Primary storage unavailableRecover from the off-cluster destinationA local Snapshot shares the failed storage domain.
  1. Record the original path, loss time, requested point, owner and consistency requirement. Identify the actual recovery copy and verify its availability.
  2. Create a separate recovery target through the supported workflow, with permissions that allow only the recovery team/owner to validate it.
  3. Compare content, metadata and application behavior. Resolve any ownership or ACL issue before placing recovered data into the live path.

05Acceptance, replacement and rollback record

  1. Preserve the live version before any approved in-place replacement when it must remain recoverable. Record the destination path and stop the specific writers that could race the replacement.
  2. After replacement, test from the actual application/user identity and confirm the new recovery copy is protected.
  3. For a failed test, disconnect only the isolated recovery target and retain evidence. An in-place restore cannot be described as trivially reversible; returning requires a preserved valid copy or a new explicit recovery decision.
Acceptance check

The owner accepts the recovered content and permissions, unaffected data is preserved, and the exact recovery point and elapsed time are recorded.

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.