Skip to main content
Element Software
A newer release of this product is available.

Reactivate the original source volume

Contributors netapp-pcarriga
PDFs

You can reestablish the original data protection relationship between the source and destination volumes when you no longer need to serve data from the destination.

About this task

The procedure below assumes that the baseline in the original source volume is intact. If the baseline is not intact, you must create and initialize the relationship between the volume you are serving data from and the original source volume before performing the procedure.

You must specify the Element source path in the form <hostip:>/lun/<name>, where “lun” is the actual string “lun” and name is the name of the Element volume.

Beginning with ONTAP 9.4, snapshot copies of a LUN created while you are serving data from the ONTAP destination are automatically replicated when the Element source is reactivated.

Replication rules are as follows:

  • Only iSCSI LUNs are supported.

  • You cannot replicate more than one LUN from an ONTAP volume to an Element volume.

  • You cannot replicate a LUN from an ONTAP volume to multiple Element volumes.

Steps

  1. Delete the original data protection relationship:

    snapmirror delete -source-path <SVM:volume>|<cluster://SVM/volume> -destination-path <hostip:>/lun/<name> -policy <policy>

    For complete command syntax, see the man page.

    The following example deletes the relationship between the original source volume, 0005 at IP address 10.0.0.11, and the volume you are serving data from, volA_dst on svm_backup:

    cluster_dst::> snapmirror delete -source-path 10.0.0.11:/lun/0005 -policy MirrorLatest -destination-path svm_backup:volA_dst

  2. Reverse the original data protection relationship:

    snapmirror resync -source-path <SVM:volume>|<cluster://SVM/volume> -destination-path <hostip:>/lun/<name> -policy <policy>

    For complete command syntax, see the man page.

    Although resync does not require a baseline transfer, it can be time-consuming. You might want to run the resync in off-peak hours.

    The following example reverses the relationship between the original source volume, 0005 at IP address 10.0.0.11, and the volume you are serving data from, volA_dst on svm_backup:

    cluster_dst::> snapmirror resync -source-path svm_backup:volA_dst -destination-path 10.0.0.11:/lun/0005 -policy MirrorLatest

  3. Update the reversed relationship:

    snapmirror update -source-path <SVM:volume>|<cluster://SVM/volume> -destination-path <hostip:>/lun/<name>

    For complete command syntax, see the man page.

    Note

    The command fails if a common snapshot copy does not exist on the source and destination. Use snapmirror initialize to re-initialize the relationship.

    The following example updates the relationship between the volume you are serving data from, volA_dst on svm_backup, and the original source volume, 0005 at IP address 10.0.0.11:

    cluster_dst::> snapmirror update -source-path svm_backup:volA_dst -destination-path 10.0.0.11:/lun/0005

  4. Stop scheduled transfers for the reversed relationship:

    snapmirror quiesce -source-path <SVM:volume>|<cluster://SVM/volume> -destination-path <hostip:>/lun/<name>

    For complete command syntax, see the man page.

    The following example stops scheduled transfers between the volume you are serving data from, volA_dst on svm_backup, and the original source volume, 0005 at IP address 10.0.0.11:

    cluster_dst::> snapmirror quiesce -source-path svm_backup:volA_dst -destination-path 10.0.0.11:/lun/0005

  5. Stop ongoing transfers for the reversed relationship:

    snapmirror abort -source-path <SVM:volume>|<cluster://SVM/volume> -destination-path <hostip:>/lun/<name>

    For complete command syntax, see the man page.

    The following example stops ongoing transfers between the volume you are serving data from, volA_dst on svm_backup, and the original source volume, 0005 at IP address 10.0.0.11:

    cluster_dst::> snapmirror abort -source-path svm_backup:volA_dst -destination-path 10.0.0.11:/lun/0005

  6. Break the reversed relationship:

    snapmirror break -source-path <SVM:volume>|<cluster://SVM/volume> -destination-path <hostip:>/lun/<name>

    For complete command syntax, see the man page.

    The following example breaks the relationship between the volume you are serving data from, volA_dst on svm_backup, and the original source volume, 0005 at IP address 10.0.0.11:

    cluster_dst::> snapmirror break -source-path svm_backup:volA_dst -destination-path 10.0.0.11:/lun/0005

  7. Delete the reversed data protection relationship:

    snapmirror delete -source-path <SVM:volume>|<cluster://SVM/volume> -destination-path <hostip:>/lun/<name> -policy <policy>

    For complete command syntax, see the man page.

    The following example deletes the reversed relationship between the original source volume, 0005 at IP address 10.0.0.11, and the volume you are serving data from, volA_dst on svm_backup:

    cluster_src::> snapmirror delete -source-path svm_backup:volA_dst -destination-path 10.0.0.11:/lun/0005 -policy MirrorLatest

  8. Reestablish the original data protection relationship:

    snapmirror resync -source-path <hostip:>/lun/<name> -destination-path <SVM:volume>|<cluster://SVM/volume>

    For complete command syntax, see the man page.

    The following example reestablishes the relationship between the original source volume, 0005 at IP address 10.0.0.11, and the original destination volume, volA_dst on svm_backup:

    cluster_dst::> snapmirror resync -source-path 10.0.0.11:/lun/0005 -destination-path svm_backup:volA_dst
After you finish

Use the snapmirror show command to verify that the SnapMirror relationship was created. For complete command syntax, see the man page.