Reactivating the source volume

After resynchronizing the data from the destination volume to the source volume, you must activate the source volume by breaking the SnapMirror relationship. You should then resynchronize the destination volume to protect the reactivated source volume.

About this task

Both the break and reverse resync operations are performed from the source cluster.

The following image shows that the source and destination volumes are read/write when you break the SnapMirror relationship. After the reverse resync operation, the data is replicated from the active source volume to the read-only destination volume.

You can reestablish the original data protection relationship between the source and destination SVMs when you no longer need to serve data from the destination. The procedure is largely identical to the procedure for volume replication, with one exception. If you set -identity-preserve true when you created the original SVM replication relationship, you must stop the destination SVM before reactivating the source SVM.

The following procedure 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.

For complete command syntax on commands, see the man page.

1. From the source SVM or the source cluster, run the following command to delete the original data protection relationship:cluster_src::> snapmirror delete -source-path svm_source: -destination-path svm_backup:
   Note

   You must enter a colon (:) after the SVM name in the -source-path and -destination-path options. See the example below.

   Example

   The following command deletes the relationship between the original source SVM snap_src1, and the SVM you are serving data from, vs1_dr: Cluster1::> snapmirror delete -source-path snap_src1:Source -destination-path vs1_dr:vol1

2. From the destination SVM or the destination cluster for the reversed relationship, run the following command to reverse the original data protection relationship: cluster_src::> snapmirror resync -source-path svm_backup: -destination-path svm_source:
   Note

   You must enter a colon (:) after the SVM name in the -source-path and -destination-path options. See the example below.

   Although resync does not require a baseline transfer, it can be time-consuming. You are advised to perform the resync in off-peak hours.

   Example

   The following command reverses the relationship between the original source SVM snap_src1, and the SVM you are serving data from, vs1_dr:

   Cluster1::> snapmirror resync -source-path vs1_dr:vol1 -destination-path snap_src1:Source
   
   Warning: All data newer than Snapshot copy snapmirror.72c07d43-77e1-11ea
   -a6b5-00a098dde696_2155326283.2020-03-14_130500 on volume snap_src1:Source will be deleted.
   
   Do you want to continue? {y|n}: y
   Operation is queued: initiate snapmirror resync to destination " snap_src1:Source ".
   
   
3. If you set -identity-preserve true when you created the SVM replication relationship, stop the source SVM for the reversed relationship: cluster_src::> vserver stop svm_backup
   Note

   It is a good idea to stop the destination SVM no matter you set -identity-preserve true or not.

   Example

   The following command stops the source SVM for the reversed relationship:

   Cluster1::> vserver stop vs1_dr:vol1
   [Job 410] Job succeeded: DONE
   
   
4. From the destination SVM or the destination cluster, run the following command to update the reversed relationship:cluster_src::> snapmirror update -source-path svm_backup: -destination-path svm_source:
   Note

   You must enter a colon (:) after the SVM name in the -source-path and -destination-path options. See the example below.

   The command fails if a common Snapshot copy does not exist on the source and destination. In this case, run the snapmirror initialize command to re-initialize the relationship.

   Example

   The following command updates the relationship between the SVM you are serving data from, vs1_dr, and the original SVM, snap_src1:

   Cluster1::> snapmirror update -source-path vs1_dr:vol1 -destination-path snap_src1:Source
   Operation is queued: snapmirror update of destination "snap_src1:source".
   
   
5. From the destination SVM or the destination cluster, run the following command to stop scheduled transfers for the reversed relationship:cluster_src::> snapmirror quiesce -source-path svm_backup: -destination-path svm_source:
   Note

   You must enter a colon (:) after the SVM name in the -source-path and -destination-path options. See the example below.

   Example

   The following command stops scheduled transfers between the SVM you are serving data from, vs1_dr, and the original SVM, snap_src1:

   Cluster1::> snapmirror quiesce -source-path vs1_dr:vol1 -destination-path snap_src1:Source
   Operation succeeded: snapmirror quiesce for destination "snap_src1:Source".
   
6. From the destination SVM or the destination cluster, run the following command to stop ongoing transfers for the reversed relationship:cluster_src::> snapmirror abort -source-path svm_backup: -destination-path svm_source:
   Note

   You must enter a colon (:) after the SVM name in the -source-path and -destination-path options. See the example below.

   Example

   The following command stops ongoing transfers between the SVM you are serving data from, vs1_dr, and the original SVM, snap_src1: Cluster1::> snapmirror abort -source-path vs1_dr:vol1 -destination-path snap_src1:Source

7. From the destination SVM or the destination cluster, run the following command to break the reversed relationship:cluster_src::> snapmirror break -source-path svm_backup: -destination-path svm_source:
   Note

   You must enter a colon (:) after the SVM name in the -source-path and -destination-path options. See the example below.

   Example

   The following command breaks the relationship between the SVM you are serving data from, vs1_dr, and the original SVM, snap_src1:Source:

   Cluster1::> snapmirror break -source-path vs1_dr:vol1 -destination-path snap_src1:Source
   [Job 128] Job succeeded: SnapMirror Break Succeeded
   
8. Start the original source SVM:cluster_dst::> vserver start svm_source

   Example

   The following command starts the original source SVM:

   Cluster2::> vserver start snap_src1
   [Job 411] Job succeeded: DONE
   
9. From the source SVM or the source cluster for the reversed relationship, run the following command to delete the reversed data protection relationship:cluster_src::> snapmirror delete -source-path svm_backup: -destination-path svm_source:
   Note

   You must enter a colon (:) after the SVM name in the -source-path and -destination-path options. See the example below.

   Example

   The following command deletes the reversed relationship between the original source SVM, snap_src1, and the SVM you are serving data from, vs1_dr:

   Cluster1::> snapmirror delete -source-path vs1_dr:vol1 -destination-path snap_src1:Source

10. Reestablish the original data protection relationship:cluster_dst::> snapmirror resync -source-path svm_source: -destination-path svm_backup:
    Note

    You must enter a colon (:) after the SVM name in the -source-path and -destination-path options. See the example below.

    Example

    The following command reestablishes the relationship between the original SVM, snap_src1, and the original destination SVM, vs1_dr:

    Cluster2::> snapmirror resync -source-path snap_src1:Source -destination-path vs1_dr:vol1
    
    Warning: All data newer than Snapshot copy snapmirror.72c07d43-77e1-11ea-
    a6b5-00a098dde696_2155326283.2020-03-14_130566 on volume vs1_dr:vol1 will be deleted.
    
    Do you want to continue? {y|n}: y
    Operation is queued: initiate snapmirror resync to destination " vs1_dr:vol1".