You might be able to use a load-sharing mirror to recover a source volume that is not accessible. This might be a good solution if you lose a source volume because a component failed, such as a shelf or port failure.
About this task
- This is not a procedure you use for recovering from a site disaster, such as a fire or flood, because both source volume and destination volume of the mirror are on the same cluster and same Storage Virtual Machine (SVM).
A site disaster would affect both sides of the mirror because of this configuration restriction. For a failure the magnitude of a site failure, you should consider using a cross-cluster disaster recovery solution.
- You should not perform the following procedure if you are backing up data to tape.
If you attempt to replace the source read-write volume with a mirrored volume using this procedure, the attempt will fail because the tape backup locks the Snapshot copy.
- If you created a junction path to a data protection destination volume and you promote the destination using the snapmirror promote command, the junction path that you created is deleted.
- Use the snapmirror promote command to make a mirror a read-write volume that replaces the source read-write volume.
The following example recovers a lost source volume from the load-sharing mirror named dept_eng_ls_mirror3 on an SVM
named vs0 and a cluster named cluster1:
cluster1::> snapmirror promote -destination-path
Data ONTAP makes the destination volume of the mirror a read-write volume, destroys the original read-write volume if it is accessible, and redirects mirrors and clients that accessed the original read-write volume to the new read-write volume.
Note: The recovered source volume might not have all of the data that the original source volume had because the SnapMirror relationship for load-sharing and data protection mirrors is a scheduled, asynchronous update and the update might not have occurred recently.