ONTAP 9

to Japanese version

Exclude LIFs and related network settings from SVM replication

If the source and destination SVMs are in different subnets, you can use the -discard-configs network option of the snapmirror policy create command to exclude LIFs and related network settings from SVM replication.

What you’ll need

The source and destination clusters and SVMs must be peered.

About this task

The -identity-preserve option of the snapmirror create command must be set to true when you create the SVM replication relationship.

For complete command syntax, see the man page.

Steps
  1. Create a destination SVM:

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

  3. Create a 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
  4. Create a custom replication policy:

    snapmirror policy create -vserver SVM -policy policy -type async-mirror|vault|mirror-vault -comment comment -tries transfer_tries -transfer-priority low|normal -is-network-compression-enabled true|false -discard-configs network

    For complete command syntax, see the man page.

    The following example creates a custom replication policy for SnapMirror DR that excludes LIFs:

    cluster_dst::> snapmirror policy create -vserver svm1 -policy DR_exclude_LIFs -type async-mirror -discard-configs network

    The following example creates a custom replication policy for unified replication that excludes LIFs:

    cluster_dst::> snapmirror policy create -vserver svm1 -policy unified_exclude_LIFs -type mirror-vault -discard-configs network
  5. From the destination SVM or the destination cluster, run the following command to create a replication relationship:

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

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

    The following example creates a SnapMirror DR relationship that excludes LIFs:

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

    The following example creates a SnapMirror unified replication relationship that excludes LIFs:

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

    vserver stop

    SVM name

    The following example stops a destination SVM named dvs1:

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

    snapmirror initialize -source-path SVM: -destination-path SVM:

    For complete command syntax, see the man page.

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

    cluster_dst::> snapmirror initialize -source-path svm1: -destination-path svm_backup:
After you finish

You must configure the network and protocols on the destination SVM for data access in the event a disaster occurs.

Top of Page