Beginning 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

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
```
From the destination cluster, create an SVM peer relationship using the vserver peer create command.

For more information, see Create an SVM intercluster peer relationship.

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 minimum supported schedule (RPO) for FlexVol volumes in an SVM SnapMirror relationship is 15 minutes. The minimum supported schedule (RPO) for FlexGroup volumes in an SVM SnapMirror relationship is 30 minutes.

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

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

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
```
Stop the destination SVM:

vserver stop

SVM name

The following example stops a destination SVM named dvs1:
```
cluster_dst::> vserver stop -vserver dvs1
```
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:
```