Skip to main content

SnapMirror synchronous disaster recovery basics

Contributors netapp-lenida netapp-ahibbard netapp-revathid netapp-aherbin
PDFs

Beginning with ONTAP 9.5, SnapMirror synchronous (SM-S) technology is supported on all FAS and AFF platforms that have at least 16 GB of memory and on all ONTAP Select platforms. SnapMirror synchronous technology is a per-node, licensed feature that provides synchronous data replication at the volume level.

This functionality addresses the regulatory and national mandates for synchronous replication in financial, healthcare, and other regulated industries where zero data loss is required.

SnapMirror synchronous operations allowed

The limit on the number of SnapMirror synchronous replication operations per HA pair depends on the controller model.

The following table lists the number of SnapMirror synchronous operations that are allowed per HA pair according to platform type and ONTAP release.

Platform

Releases earlier than ONTAP 9.9.1

ONTAP 9.9.1

ONTAP 9.10.1

ONTAP 9.11.1 through ONTAP 9.14.1

AFF

80

160

200

400

ASA

80

160

200

400

FAS

40

80

80

80

ONTAP Select

20

40

40

40

Supported features

The following table indicates the features supported with SnapMirror synchronous and the ONTAP releases in which support is available.

Feature

Release first supported

Additional information

Antivirus on the primary volume of the SnapMirror synchronous relationship

ONTAP 9.6

Application-created Snapshot copy replication

ONTAP 9.7

If a Snapshot copy is tagged with the appropriate label at the time of the snapshot create operation, using the CLI or the ONTAP API, SnapMirror synchronous replicates the Snapshot copies, both user created or those created with external scripts, after quiescing the applications. Scheduled Snapshot copies created using a Snapshot policy are not replicated. For more information about replicating application-created Snapshot copies, see the Knowledge Base article: How to replicate application created snapshots with SnapMirror synchronous.

Clone auto delete

ONTAP 9.6

FabricPool aggregates with tiering policy of None, Snapshot, or Auto are supported with SnapMirror synchronous source and destination.

ONTAP 9.5

The destination volume in a FabricPool aggregate cannot be set to All tiering policy.

FC

ONTAP 9.5

Over all networks for which latency does not exceed 10ms

FC-NVMe

ONTAP 9.7

File clones

ONTAP 9.7

FPolicy on the primary volume of the SnapMirror synchronous relationship

ONTAP 9.6

Hard and soft quotas on the primary volume of the SnapMirror synchronous relationship

ONTAP 9.6

The quota rules are not replicated to the destination; therefore, the quota database is not replicated to the destination.

Intra-cluster synchronous relationships

ONTAP 9.14.1

High availability is provided when source and destination volumes are placed on different HA pairs.
If the entire cluster goes down, access to volumes will not be possible until the cluster is recovered.
Intra-cluster SnapMirror synchronous relationships will contribute to the overall limit of simultaneous relationships per HA pair.

iSCSI

ONTAP 9.5

LUN clones and NVMe namespace clones

ONTAP 9.7

LUN clones backed by application-created Snapshot copies

ONTAP 9.7

Mixed protocol access (NFS v3 and SMB)

ONTAP 9.6

NDMP/NDMP restore

ONTAP 9.13.1

Both the source and destination cluster must be running ONTAP 9.13.1 or later to use NDMP with SnapMirror Synchronous. For more information, see Transfer data using ndmp copy.

Non-disruptive SnapMirror synchronous operations (NDO) on AFF/ASA platforms, only.

ONTAP 9.12.1

Support for non-disruptive operations enables you to perform many common maintenance tasks without scheduling down time. Operations supported include takeover and giveback, and volume move, provided that a single node is surviving among each of the two clusters.

NFS v4.2

ONTAP 9.10.1

NFS v4.3

ONTAP 9.5

NFS v4.0

ONTAP 9.6

NFS v4.1

ONTAP 9.6

NVMe/TCP

9.10.1

Removal of high metadata operation frequency limitation

ONTAP 9.6

Security for sensitive data in-transit using TLS 1.2 encryption

ONTAP 9.6

Single file and partial file restore

ONTAP 9.13.1

SMB 2.0 or later

ONTAP 9.6

SnapMirror synchronous mirror-mirror cascade

ONTAP 9.6

The relationship from the destination volume of the SnapMirror synchronous relationship must be an SnapMirror asynchronous relationship.

SVM disaster recovery

ONTAP 9.6

* A SnapMirror synchronous source can also be a SVM disaster recovery source, for example, a fan-out configuration with SnapMirror synchronous as one leg and SVM disaster recovery as the other.

* A SnapMirror synchronous source cannot be an SVM disaster recovery destination because SnapMirror synchronous does not support cascading a data protection source.
You must release the synchronous relationship before performing an SVM disaster recovery flip resync in the destination cluster.

* A SnapMirror synchronous destination cannot be an SVM disaster recovery source because SVM disaster recovery does not support replication of DP volumes.
A flip resync of the synchronous source would result in the SVM disaster recovery excluding the DP volume in the destination cluster.

Tape-based restore to the source volume

ONTAP 9.13.1

Timestamp parity between source and destination volumes for NAS

ONTAP 9.6

If you have upgraded from ONTAP 9.5 to ONTAP 9.6, the timestamp is replicated only for any new and modified files in the source volume. The timestamp of existing files in the source volume is not synchronized.

Unsupported features

The following features are not supported with SnapMirror synchronous relationships:

  • Consistency groups

  • DP_Optimized (DPO) systems

  • FlexGroup volumes

  • FlexCache volumes

  • Global throttling

  • In a fan-out configuration, only one relationship can be a SnapMirror synchronous relationship; all the other relationships from the source volume must be SnapMirror asynchronous relationships.

  • LUN move

  • MetroCluster configurations

  • Mixed SAN and NVMe access
    LUNs and NVMe namespaces are not supported on the same volume or SVM.

  • SnapCenter

  • SnapLock volumes

  • Tamperproof Snapshot copies

  • Tape backup or restore using dump and SMTape on the destination volume

  • Throughput floor (QoS Min) for source volumes

  • Volume SnapRestore

  • VVol

Modes of operation

SnapMirror synchronous has two modes of operation based on the type of the SnapMirror policy used:

  • Sync mode
    In Sync mode, application I/O operations are sent in parallel to the primary and secondary
    storage systems. If the write to the secondary storage is not completed for any reason, the application is allowed to continue writing to the primary storage. When the error condition is corrected, SnapMirror synchronous technology automatically resynchronizes with the secondary storage and resumes replicating from primary storage to secondary storage in synchronous mode.
    In Sync mode, RPO=0 and RTO is very low until a secondary replication failure occurs at which time RPO and RTO become indeterminate, but equal the time to repair the issue that caused secondary replication to fail and for the resync to complete.

  • StrictSync mode
    SnapMirror synchronous can optionally operate in StrictSync mode. If the write to the secondary storage is not completed for any reason, the application I/O fails, thereby ensuring that the primary and secondary storage are identical. Application I/O to the primary resumes only after the SnapMirror relationship returns to the InSync status. If the primary storage fails, application I/O can be resumed on the secondary storage, after failover, with no loss of data.
    In StrictSync mode RPO is always zero, and RTO is very low.

Relationship status

The status of a SnapMirror synchronous relationship is always in the InSync status during normal operation. If the SnapMirror transfer fails for any reason, the destination is not in sync with the source and can go to the OutofSync status.

For SnapMirror synchronous relationships, the system automatically checks the relationship status (InSync or OutofSync) at a fixed interval. If the relationship status is OutofSync, ONTAP automatically triggers the auto resync process to bring back the relationship to the InSync status. Auto resync is triggered only if the transfer fails due to any operation, such as unplanned storage failover at source or destination or a network outage. User-initiated operations such as snapmirror quiesce and snapmirror break do not trigger auto resync.

If the relationship status becomes OutofSync for a SnapMirror synchronous relationship in the StrictSync mode, all I/O operations to the primary volume are stopped. The OutofSync state for SnapMirror synchronous relationship in the Sync mode is not disruptive to the primary and I/O operations are allowed on the primary volume.

Related information

NetApp Technical Report 4733: SnapMirror synchronous configuration and best practices