Understanding SnapMirror SVM replication

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

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:

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
Configuration replicated		Policy without -discard-configs network set	Policy with -discard-configs network set	-identity-preserve false
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
SNMP	v3 users	Yes	Yes	No