Replicate an entire SVM configuration

Contributors

You can use the -identity-preserve true option of the snapmirror create command to replicate an entire SVM configuration.

What you’ll need

The source and destination clusters and SVMs must be peered.

For complete command syntax, see the man page.

About this task

This workflow assumes that you are already using a default policy or a custom replication policy.

Starting with ONTAP 9.9.1, when you use the mirror-vault policy, you can create different Snapshot policies on the source and destination SVM, and the Snapshot copies on the destination are not overwritten by Snapshot copies on the source. For more information, see Understanding SnapMirror SVM replication.

Steps
  1. Create a destination SVM:

    vserver create -vserver SVM_name -subtype dp-destination

    The SVM name must be unique across the source and destination clusters.

    The following example creates a destination SVM named svm_backup:

    cluster_dst:> vserver create -vserver svm_backup -subtype dp-destination
  2. Create a replication job schedule:

    job schedule cron create -name job_name -month month -dayofweek day_of_week -day day_of_month -hour hour -minute minute

    For -month, -dayofweek, and -hour, you can specify all to run the job every month, day of the week, and hour, respectively.

    The following example creates a job schedule named my_weekly that runs on Saturdays at 3:00 a.m.:

    cluster_dst::> job schedule cron create -name my_weekly -dayofweek "Saturday" -hour 3 -minute 0
  3. From the destination SVM or the destination cluster, create a replication relationship:

    snapmirror create -source-path SVM_name: -destination-path SVM_name: -type DP|XDP -schedule schedule -policy policy -identity-preserve true

    Note

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

    The following example creates a SnapMirror DR relationship using the default MirrorAllSnapshots policy:

    cluster_dst::> snapmirror create -source-path svm1: -destination-path svm_backup: -type XDP -schedule my_daily -policy MirrorAllSnapshots -identity-preserve true

    The following example creates a unified replication relationship using the default MirrorAndVault policy:

    cluster_dst:> snapmirror create -source-path svm1: -destination-path svm_backup: -type XDP -schedule my_daily -policy MirrorAndVault -identity-preserve true

    Assuming you have created a custom policy with the policy type async-mirror, the following example creates a SnapMirror DR relationship:

    cluster_dst::> snapmirror create -source-path svm1: -destination-path svm_backup: -type XDP -schedule my_daily -policy my_mirrored -identity-preserve true

    Assuming you have created a custom policy with the policy type mirror-vault, the following example creates a unified replication relationship:

    cluster_dst::> snapmirror create -source-path svm1: -destination-path svm_backup: -type XDP -schedule my_daily -policy my_unified -identity-preserve true
  4. Stop the destination SVM:

    vserver stop

    SVM name

    The following example stops a destination SVM named dvs1:

    cluster_dst::> vserver stop -vserver dvs1
  5. From the destination SVM or the destination cluster, initialize the SVM replication relationship:

    snapmirror initialize -source-path SVM_name: -destination-path SVM_name:

    The following example initializes the relationship between the source SVM, svm1, and the destination SVM, svm_backup:

    cluster_dst::> snapmirror initialize -source-path svm1: -destination-path svm_backup: