Skip to main content

Configure an ONTAP SnapMirror replication relationship in one step

Contributors netapp-aaron-holt netapp-aherbin netapp-lenida netapp-dbagwell netapp-thomi
PDFs

You can use the snapmirror protect command to configure a data protection relationship in a single step. You specify a list of volumes to be replicated, an SVM on the destination cluster, a job schedule, and a SnapMirror policy. snapmirror protect does the rest.

Before you begin

  • The source and destination clusters and SVMs must be peered.

    Cluster and SVM peering

  • The language on the destination volume must be the same as the language on the source volume.

  • Beginning with ONTAP 9.20.1, you can configure backend SnapMirror asynchronous replication over existing FC fabrics. To do so, your ONTAP system backend must be configured for FC replication and both the FC fabric and the intercluster IP network must be operational. Replication data can transport over the FC fabric, but the intercluster IP network is required for cluster communications and replication management functions. Direct-attached FC configurations are not supported for backend FC replication. Learn to configure your ONTAP system backend for FC replication

    • If you are configuring a SnapMirror asynchronous relationship to use FC as the transport protocol, in a MetroCluster configuration, the storage initiator used for the MetroCluster must be separate from the initiator used for replication over FC. Sharing initiator storage between the two is not supported.

About this task

The snapmirror protect command chooses an aggregate associated with the specified SVM. If no aggregate is associated with the SVM, it chooses from all the aggregates in the cluster. The choice of aggregate is based on the amount of free space and the number of volumes on the aggregate.

The snapmirror protect command then performs the following steps:

  • Creates a destination volume with an appropriate type and amount of reserved space for each volume in the list of volumes to be replicated.

    The name of the destination volume is of the form source_volume_name_dst. In case of a conflict with an existing name, the command appends a number to the volume name. You can specify a prefix and/or suffix in the command options. The suffix replaces the system-supplied dst suffix.

    A destination volume can contain up to 1019 snapshots.

  • Configures a replication relationship appropriate for the policy you specify.

  • Initializes the relationship.

    Note

    Initialization can be time-consuming. snapmirror protect does not wait for initialization to complete before the job finishes. For this reason, you should use the snapmirror show command rather than the job show command to determine when initialization is complete.

  • Beginning with ONTAP 9.20.1, use a supported asynchronous data protection policy and the -transport fc option when creating your Snapmirror relationship to replicate over your FC fabric. Backend replication uses the IP protocol by default. Learn which default asynchronous data protection policies are supported for backend FC replication.

    Note To change the selected transport protocol after creating a SnapMirror replication relationship, you must delete and recreate the relationship.
Step

  1. Create and initialize a replication relationship in one step:

    You must replace the variables in angle brackets with the required values before running this command.

    snapmirror protect -path-list <SVM:volume> -destination-vserver <destination_SVM> -policy <policy> -schedule <schedule> -auto-initialize <true|false> -destination-volume-prefix <prefix> -destination-volume-suffix <suffix>
    Note

    You must run this command from the destination SVM or the destination cluster. The -auto-initialize option defaults to “true”.

    The following example creates and initializes a SnapMirror DR relationship using the default MirrorAllSnapshots policy and the FC transport protocol:

    cluster_dst::> snapmirror protect -path-list svm1:volA, svm1:volB -destination-vserver svm_backup -policy MirrorAllSnapshots -schedule replication_daily -transport fc
    Note

    You can use a custom policy if you prefer. For more information, see Creating a custom replication policy.

    The following example creates and initializes a SnapVault relationship using the default XDPDefault policy:

    cluster_dst::> snapmirror protect -path-list svm1:volA, svm1:volB -destination-vserver svm_backup -policy XDPDefault -schedule replication_daily

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

    cluster_dst::> snapmirror protect -path-list svm1:volA, svm1:volB -destination-vserver svm_backup -policy MirrorAndVault

    The following example creates and initializes a SnapMirror synchronous relationship using the default Sync policy:

    cluster_dst::> snapmirror protect -path-list svm1:volA, svm1:volB -destination-vserver svm_sync -policy Sync
    Note

    For SnapVault and unified replication policies, you might find it useful to define a schedule for creating a copy of the last transferred snapshot on the destination. For more information, see Defining a schedule for creating a local copy on the destination.
After you finish

Use the snapmirror show command to verify that the SnapMirror relationship was created.

Learn more about snapmirror show in the ONTAP command reference.

Related information