Home / Troubleshooting / Backup & restore

Backup restore troubleshooting

A recovery-first ONTAP 9.x runbook: identify the usable copy, prove it is the right point in time, and choose the least destructive restore path.

Recovery control plane

Restore the evidence before you restore the data

Preserve the current volume, relationship state, job history, and backup catalog. A clone or alternate-path restore is usually safer than overwriting production.

01 / INVENTORYsnapshot → vault → NDMP02 / VALIDATEtime · scope · integrity03 / RECOVERclone → copy → cut over

1. First 10 minutes: freeze and inventory

Do not start with resync, initialize, or snapshot deletion. Those operations can change the recovery evidence. If ransomware, legal hold, or broad corruption is suspected, isolate client access and follow the incident process before restoring.

Record the requested path, last-known-good time, application consistency requirement, current client access, and acceptable downtime. Then collect read-only state.

cluster::> volume show -vserver svm1 -volume data1 \
  -fields state,type,size,available,percent-used,junction-path
cluster::> volume snapshot show -vserver svm1 -volume data1 \
  -fields snapshot,create-time,size,owners
cluster::> snapmirror show -source-path svm1:data1 \
  -fields destination-path,relationship-status,mirror-state,lag-time,last-transfer-end
cluster::> job show -state Failure
cluster::> event log show -time >1h -severity * \
  -message-name *snapmirror*

volume snapshot show output is local to the cluster where it runs. Repeat it on the vault destination. Snapshot names alone do not prove application consistency; confirm the creating application or policy.

2. Choose the smallest recovery

Loss	Preferred first move	Why
One file or directory	Copy from `.snapshot`, or mount a clone	No production-volume rollback.
Many files, source healthy	FlexClone the chosen Snapshot, validate, then copy	Preserves newer production data.
Whole volume corrupt or lost	Restore to a new volume when capacity and namespace allow	Supports comparison and rollback.
Primary site unavailable	Use the documented DR activation workflow	A restore is not the same as DR failover.
Only tape/VTL copy remains	Restore through the backup application's NDMP catalog	The media server owns file history and tape positioning.

For SnapMirror DR activation, use the SnapMirror troubleshooting runbook. For whole-SVM recovery, use the SVM DR guide.

3. Local Snapshot recovery

File or directory

If Snapshot directory visibility and client permissions allow it, copy the object from the volume's .snapshot directory. For controlled recovery, create a clone and expose it under a temporary junction.

cluster::> volume clone create -vserver svm1 -flexclone data1_recovery \
  -type RW -parent-volume data1 -parent-snapshot hourly.2026-08-28_1005
cluster::> volume mount -vserver svm1 -volume data1_recovery \
  -junction-path /recovery/data1
cluster::> volume show -vserver svm1 -volume data1_recovery \
  -fields junction-path,state,type

Validate ownership, ACLs, timestamps, file count, and application readability before copying. After acceptance, unmount and delete the temporary clone according to local change control.

Whole-volume rollback

Destructive boundary: volume snapshot restore replaces the active file system with the selected Snapshot and discards changes made after it. Stop clients and take a fresh Snapshot first if the incident process permits.

cluster::> volume snapshot create -vserver svm1 -volume data1 \
  -snapshot pre_restore_hold
cluster::> volume snapshot restore -vserver svm1 -volume data1 \
  -snapshot hourly.2026-08-28_1005

Exact restore eligibility can be blocked by relationships, clones, or other owners. Read the CLI warning; do not add force options merely to bypass a veto.

4. Restore from a SnapMirror vault

First identify snapshots on the destination and confirm the relationship. Modern vault relationships normally use type XDP; the retention behavior comes from the policy rules and SnapMirror labels.

backup::> snapmirror show -destination-path backup_svm:data1_vault \
  -fields source-path,policy,mirror-state,relationship-status,lag-time
backup::> volume snapshot show -vserver backup_svm -volume data1_vault \
  -fields snapshot,create-time,snapmirror-label,owners

Run the restore from the destination cluster. The destination of this command is the volume receiving recovered data; confirm both paths before accepting the prompt.

backup::> snapmirror restore \
  -source-path backup_svm:data1_vault \
  -destination-path svm1:data1_recovery \
  -source-snapshot daily.2026-08-27_0010
backup::> snapmirror show -destination-path svm1:data1_recovery \
  -fields relationship-status,mirror-state,healthy,unhealthy-reason
backup::> snapmirror show-history -destination-path svm1:data1_recovery

The exact topology and ONTAP release determine whether the target volume must already exist and which relationship state is permitted. Use snapmirror restore ? and the command reference for the running release. Do not break or resync an existing DR relationship as an assumed prerequisite.

When the restore will not start

Verify cluster and SVM peer health with cluster peer health show and vserver peer show.
Check the selected Snapshot exists on the vault and is not a partial transfer.
Confirm destination capacity, volume state, encryption/key availability, and name resolution.
Inspect snapmirror show -fields unhealthy-reason, job failure details, and EMS before changing the relationship.

5. NDMP restore failures

ONTAP provides the NDMP data mover; the backup product owns the catalog, media selection, and restore request. Start on both sides. Do not invent a tape restore at the ONTAP CLI when the backup catalog is authoritative.

cluster::> vserver services ndmp show -vserver svm1
cluster::> vserver services ndmp status -vserver svm1
cluster::> network interface show -vserver svm1 \
  -fields lif,status-oper,address,home-node,home-port

Symptom	Check	Next move
Authentication rejected	SVM scope, NDMP user, auth type, credential age	Validate the login configured in the backup product; rotate deliberately.
Control connection timeout	NDMP service, data LIF route, firewall, port expected by the product	Test from the media server and preserve packet evidence.
Media/tape unavailable	Backup catalog, library robotics, drive reservation	Resolve in the backup product or library; ONTAP cannot fix absent media.
Restore succeeds but path is wrong	Backup root and destination path mapping	Restore to a clean alternate volume, then copy the intended subtree.
ACL or identity mismatch	Security style, name services, SID/UID resolution	Validate on an isolated restore target before client cutover.

For commands and behavior specific to the installed backup application, use that vendor's compatibility matrix. NDMP capability and supported topologies vary by ONTAP release and backup product.

6. Cluster configuration backup is not data backup

ONTAP configuration backups protect cluster and node configuration. They do not contain user volume data. Inspect archives before treating one as a recovery source.

cluster::> system configuration backup show
cluster::> system configuration backup create \
  -node node1 -backup-name before_maintenance.7z
cluster::> system configuration backup upload \
  -node node1 -backup before_maintenance.7z \
  -destination ftp://backup.example/ontap/node1/

Escalation boundary: configuration restore and node recovery are platform- and failure-specific procedures. Do not run system configuration recovery cluster restore on a live cluster from a generic runbook. Engage NetApp Support when quorum, root aggregate, or cluster identity is in doubt.

7. Failure matrix

Signal	Likely domain	Safe evidence
Requested Snapshot missing locally	Retention, autodelete, policy	Check vault, clone owners, and policy schedule; do not delete newer copies.
Vault lag grows	Transfer, network, capacity	`snapmirror show`, history, peer health, volume space, EMS.
`Destination volume is not initialized`	Relationship state	Confirm intended source/destination and whether this is a new target.
Restore target fills	Capacity or Snapshot growth	Pause through the owning product if supported; add capacity only after sizing.
Recovered application will not open	Crash consistency, dependency ordering	Preserve the copy; validate logs and application-consistent backup metadata.
Encryption keys unavailable	Key management	Check onboard/external key manager status; do not rekey or destroy key records.

Official command references

Examples target the ONTAP 9.19.1 CLI reference and use placeholder SVM, volume, cluster, and Snapshot names. Verify syntax with command ? on the exact ONTAP release before production use.