Understanding SnapMirror SVM replication

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:

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.

Compatible ONTAP versions for SnapMirror relationships

How SVM configurations are replicated

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

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
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