About SnapMirror SVM replication

Contributors

You can use SnapMirror to create a data protection relationship between SVM. In this type of data protection relationship, all or part of the SVM’s configuration, from NFS exports and SMB shares to RBAC, is replicated, as well as the data in the volumes that the SVM owns.

Supported relationship types

Only data-serving SVM can be replicated. The following data protection relationship types are supported:

  • SnapMirror DR, in which the destination typically contains only the Snapshot copies currently on the source.

    Starting with ONTAP 9.9.1, this behavior changes when you are using the mirror-vault policy. Starting in ONTAP 9.9.1, you can create different Snapshot policies on the source and destination, and the Snapshot copies on the destination are not overwritten by Snapshot copies on the source:

    • They are not overwritten from the source to the destination during normal scheduled operations, updates and resync

    • They are not deleted during break operations.

    • They are not deleted during flip-resync operations. When you configure an SVM DR relationship using the mirror-vault policy using ONTAP 9.9.1 and later, the policy behaves as follows:

    • User-defined Snapshot copy policies at the source are not copied to the destination.

    • System-defined Snapshot copy policies are not copied to the destination.

    • Volume association with user and system defined Snapshot policies are not copied to the destination.
      SVM.

  • Starting with ONTAP 9.2, SnapMirror unified replication, in which the destination is configured for both DR and long-term retention.

Details about these relationship types can be found here: Understanding SnapMirror volume replication.

The policy type of the replication policy determines the type of relationship it supports. The following table shows the available policy types.

Policy type Relationship type

async-mirror

SnapMirror DR

mirror-vault

Unified replication

XDP replaces DP as the SVM replication default in ONTAP 9.4

Starting with ONTAP 9.4, SVM data protection relationships default to XDP mode. SVM data protection relationships continue to default to DP mode in ONTAP 9.3 and earlier.

Existing relationships are not affected by the new default. If a relationship is already of type DP, it will continue to be of type DP. The following table shows the behavior you can expect.

If you specify…​ The type is…​ The default policy (if you do not specify a policy) is…​

DP

XDP

MirrorAllSnapshots (SnapMirror DR)

Nothing

XDP

MirrorAllSnapshots (SnapMirror DR)

XDP

XDP

MirrorAndVault (Unified replication)

Details about the changes in the default can be found here: XDP replaces DP as the SnapMirror default.

Note

Version-independence is not supported for SVM replication.

How SVM configurations are replicated

The content of an SVM replication relationship is determined by the interaction of the following fields:

  • The -identity-preserve true option of the snapmirror create command replicates the entire SVM configuration.

    The -identity-preserve false option replicates only the volumes and authentication and authorization configurations of the SVM, and the protocol and name service settings listed in Configurations replicated in SVM DR relationships.

  • The -discard-configs network option of the snapmirror policy create command excludes LIFs and related network settings from SVM replication, for use in cases where the source and destination SVMs are in different subnets.

  • The -vserver-dr-protection unprotected option of the volume modify command excludes the specified volume from SVM replication.

Otherwise, SVM replication is almost identical to volume replication. You can use virtually the same workflow for SVM replication as you use for volume replication.

Support details

The following table shows support details for SnapMirror SVM replication.

Resource or feature Support details

Relationship types

  • SnapMirror DR

  • Starting with ONTAP 9.2, SnapMirror unified replication

Replication scope

Intercluster only. You cannot replicate SVMs in the same cluster.

Version-independence

Not supported.

Deployment types

  • Single source to single destination

  • Starting with ONTAP 9.4, fan-out. You can fan-out to two destinations only.

    By default, only one -identity-preserve true relationship is allowed per source SVM.

Volume encryption

  • Encrypted volumes on the source are encrypted on the destination.

  • Onboard Key Manager or KMIP servers must be configured on the destination.

  • New encryption keys are generated at the destination.

  • If the destination does not contain a node that supports volume .encryption, replication succeeds, but the destination volumes are not encrypted.

FabricPool

Starting with ONTAP 9.6, SnapMirror SVM replication is supported with FabricPools.

MetroCluster

Starting with ONTAP 9.5, SnapMirror SVM replication is supported on MetroCluster configurations.

  • A MetroCluster configuration cannot be the destination of an SVM DR relationship.

  • Only an active SVM within a MetroCluster configuration can be the source of an SVM DR relationship.

    A source can be a sync-source SVM before switchover or a sync-destination SVM after switchover.

  • When a MetroCluster configuration is in a steady state, the MetroCluster sync-destination SVM cannot be the source of an SVM DR relationship, since the volumes are not online.

  • When the sync-source SVM is the source of an SVM DR relationship, the source SVM DR relationship information is replicated to the MetroCluster partner.

  • During the switchover and switchback processes, replication to the SVM DR destination might fail.

    However, after the switchover or switchback process completes, the next SVM DR scheduled updates will succeed.

SnapMirror Synchronous

Not supported with SVM DR.

Configurations replicated in SVM DR relationships

The following table shows the interaction of the snapmirror create `-identity-preserve option and the snapmirror policy create -discard-configs network` option:

Configuration replicated ‑identity‑preserve true ‑identity‑preserve false

Policy without -discard-configs network set

Policy with -discard-configs network set

Network

NAS LIFs

Yes

No

No

LIF Kerberos configuration

Yes

No

No

SAN LIFs

No

No

No

Firewall policies

Yes

Yes

No

Routes

Yes

No

No

Broadcast domain

No

No

No

Subnet

No

No

No

IPspace

No

No

No

CIFS

CIFS server

Yes

Yes

No

Local groups and local user

Yes

Yes

Yes

Privilege

Yes

Yes

Yes

Shadow copy

Yes

Yes

Yes

BranchCache

Yes

Yes

Yes

Server options

Yes

Yes

Yes

Server security

Yes

Yes

No

Home directory, share

Yes

Yes

Yes

Symlink

Yes

Yes

Yes

Fpolicy policy, Fsecurity policy, and Fsecurity NTFS

Yes

Yes

Yes

Name mapping and group mapping

Yes

Yes

Yes

Audit information

Yes

Yes

Yes

NFS

Export policies

Yes

Yes

No

Export policy rules

Yes

Yes

No

NFS server

Yes

Yes

No

RBAC

Security certificates

Yes

Yes

No

Login user, public key, role, and role configuration

Yes

Yes

Yes

SSL

Yes

Yes

No

Name services

DNS and DNS hosts

Yes

Yes

No

UNIX user and UNIX group

Yes

Yes

Yes

Kerberos realm and Kerberos keyblocks

Yes

Yes

No

LDAP and LDAP client

Yes

Yes

No

Netgroup

Yes

Yes

No

NIS

Yes

Yes

No

Web and web access

Yes

Yes

No

Volume

Object

Yes

Yes

Yes

Snapshot copies, Snapshot policy, and autodelete policy

Yes

Yes

Yes

Efficiency policy

Yes

Yes

Yes

Quota policy and quota policy rule

Yes

Yes

Yes

Recovery queue

Yes

Yes

Yes

Root volume

Namespace

Yes

Yes

Yes

User data

No

No

No

Qtrees

No

No

No

Quotas

No

No

No

File-level QoS

No

No

No

Attributes: state of the root volume, space guarantee, size, autosize, and total number of files

No

No

No

Storage QoS

QoS policy group

Yes

Yes

Yes

Fibre Channel (FC)

No

No

No

iSCSI

No

No

No

LUNs

Object

Yes

Yes

Yes

igroups

No

No

No

portsets

No

No

No

Serial numbers

No

No

No

SNMP

v3 users

Yes

Yes

No