Skip to main content

About SnapMirror SVM replication

Contributors netapp-lenida netapp-aherbin netapp-ahibbard netapp-dbagwell netapp-thomi
PDFs

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.

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

For more information about SnapMirror unified replication, see SnapMirror unified replication basics.

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

Beginning 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. 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.4, 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.2, SnapMirror unified replication

Replication scope

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

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

Beginning with ONTAP 9.6, 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.

Beginning with ONTAP 9.5, 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, and it must meet all necessary requirements described in TR-4966: Migrating a SVM into a MetroCluster solution.

  • 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 and Snapshot policy

Yes

Yes

Yes

Autodelete policy

No

No

No

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

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. Refer to the Hardware Universe to learn the limits for your specific configuration.

Storage object

Limit

SVM

300 Flexible volumes

HA pair

1,000 Flexible Volumes

Cluster

128 SVM disaster relationships