You can use SnapMirror to create a data protection relationship between SVMs. 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 SVMs 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.

Beginning with ONTAP 9.9.1, this behavior changes when you are using the mirror-vault policy. Beginning with 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 disaster 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.
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

Policy type

Relationship type

async-mirror

SnapMirror DR

mirror-vault

Unified replication

XDP replaces DP as the SVM replication default in ONTAP 9.7

Beginning with ONTAP 9.7, SVM data protection relationships default to XDP mode.

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)

If you specify…

The type is…

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

XDP

MirrorAllSnapshots (SnapMirror DR)

Nothing

XDP

MirrorAllSnapshots (SnapMirror DR)

XDP

MirrorAndVault (Unified replication)

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

Version-independence is not supported for SVM replication. In an SVM disaster recovery configuration, the destination SVM must be on a cluster running the same ONTAP version as the source SVM cluster to support failover and fail back operations.

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 disaster recovery 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
Deployment types	Single source to single destination Beginning with ONTAP 9.7, fan-out. You can fan-out to two destinations only. By default, only one -identity-preserve true relationship is allowed per source SVM.
Relationship types	SnapMirror disaster recovery Beginning with ONTAP 9.7, SnapMirror unified replication
Replication scope	Intercluster only. You cannot replicate SVMs in the same cluster.
Autonomous Ransomware Protection	Supported beginning with ONTAP 9.12.1. For more information, see Autonomous Ransomware Protection
Consistency groups asynchronous support	Beginning with ONTAP 9.14.1, a maximum of 32 SVM disaster recovery relationships are supported when consistency groups exist. See Protect a consistency group and Consistency group limits for more information.
FabricPool	SnapMirror SVM replication is supported with FabricPools.
MetroCluster	Beginning with ONTAP 9.11.1, both sides of a SVM disaster recovery relationship within a MetroCluster configuration can act as a source for additional SVM disaster recovery configurations. SnapMirror SVM replication is supported on MetroCluster configurations. In releases earlier than ONTAP 9.10.X, a MetroCluster configuration cannot be the destination of an SVM disaster recovery relationship. In ONTAP 9.10.1 and later releases, a MetroCluster configuration can be the destination of an SVM disaster recovery relationship for migration purposes only. Only an active SVM within a MetroCluster configuration can be the source of an SVM disaster recovery 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 disaster recovery relationship, since the volumes are not online. When the sync-source SVM is the source of an SVM disaster recovery relationship, the source SVM disaster recovery relationship information is replicated to the MetroCluster partner. During the switchover and switchback processes, replication to the SVM disaster recovery destination might fail. However, after the switchover or switchback process completes, the next SVM disaster recovery scheduled updates will succeed.
Consistency group	Supported beginning with ONTAP 9.14.1. For more information, see Protect a consistency group.
ONTAP S3	Not supported with SVM disaster recovery.
SnapMirror Synchronous	Not supported with SVM disaster recovery.
Version-independence	Not supported.
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.

Resource or feature

Support details

Deployment types

Single source to single destination
Beginning with ONTAP 9.7, fan-out. You can fan-out to two destinations only.

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

Relationship types

SnapMirror disaster recovery
Beginning with ONTAP 9.7, SnapMirror unified replication

Replication scope

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

Autonomous Ransomware Protection

Supported beginning with ONTAP 9.12.1. For more information, see Autonomous Ransomware Protection

Consistency groups asynchronous support

Beginning with ONTAP 9.14.1, a maximum of 32 SVM disaster recovery relationships are supported when consistency groups exist. See Protect a consistency group and Consistency group limits for more information.

FabricPool

SnapMirror SVM replication is supported with FabricPools.

MetroCluster

Beginning with ONTAP 9.11.1, both sides of a SVM disaster recovery relationship within a MetroCluster configuration can act as a source for additional SVM disaster recovery configurations.

SnapMirror SVM replication is supported on MetroCluster configurations.

In releases earlier than ONTAP 9.10.X, a MetroCluster configuration cannot be the destination of an SVM disaster recovery relationship.
In ONTAP 9.10.1 and later releases, a MetroCluster configuration can be the destination of an SVM disaster recovery relationship for migration purposes only.
Only an active SVM within a MetroCluster configuration can be the source of an SVM disaster recovery 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 disaster recovery relationship, since the volumes are not online.
When the sync-source SVM is the source of an SVM disaster recovery relationship, the source SVM disaster recovery relationship information is replicated to the MetroCluster partner.
During the switchover and switchback processes, replication to the SVM disaster recovery destination might fail.

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

Consistency group

Supported beginning with ONTAP 9.14.1. For more information, see Protect a consistency group.

ONTAP S3

Not supported with SVM disaster recovery.

SnapMirror Synchronous

Not supported with SVM disaster recovery.

Version-independence

Not supported.

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.

Configurations replicated in SVM disaster recovery 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
Service policies	Yes	Yes	No
Routes	Yes	No	No
Broadcast domain	No	No	No
Subnet	No	No	No
IPspace	No	No	No
SMB	SMB 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

Configuration replicated

‑identity‑preserve true

‑identity‑preserve false

Policy without -discard-configs network set

Policy with -discard-configs network set

Network

NAS LIFs

Yes

LIF Kerberos configuration

Yes

SAN LIFs

Firewall policies

Yes

Service policies

Yes

Routes

Yes

Broadcast domain

Subnet

IPspace

SMB

SMB server

Yes

Local groups and local user

Yes

Privilege

Yes

Shadow copy

Yes

BranchCache

Yes

Server options

Yes

Server security

Yes

Home directory, share

Yes

Symlink

Yes

Fpolicy policy, Fsecurity policy, and Fsecurity NTFS

Yes

Name mapping and group mapping

Yes

Audit information

Yes

NFS

Export policies

Yes

Export policy rules

Yes

NFS server

Yes

RBAC

Security certificates

Yes

SSL

Yes

Name services

DNS and DNS hosts

Yes

UNIX user and UNIX group

Yes

Kerberos realm and Kerberos keyblocks

Yes

LDAP and LDAP client

Yes

Netgroup

Yes

NIS

Yes

Web and web access

Yes

Volume

Object

Yes

Snapshot copies, Snapshot policy, and autodelete policy

Yes

Efficiency policy

Yes

Quota policy and quota policy rule

Yes

Recovery queue

Yes

Root volume

Namespace

Yes

User data

Qtrees

Quotas

File-level QoS

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

Storage QoS

QoS policy group

Yes

Fibre Channel (FC)

iSCSI

LUNs

Object

Yes

igroups

portsets

Serial numbers

SNMP

v3 users

Yes

SVM disaster recovery storage limits

The following table shows the recommended maximum number of volumes and SVM disaster recovery relationships supported per storage object. You should be aware that limits are often platform dependent.

Storage object	Limit
SVM	300 Flexible volumes
HA pair	1,000 Flexible Volumes
Cluster	128 SVM disaster relationships

Storage object

Limit

SVM

300 Flexible volumes

HA pair

1,000 Flexible Volumes

Cluster

128 SVM disaster relationships