Zero-RPO and Zero-RTO for NAS
For years, zero recovery point objective (RPO) for NAS workloads has been achieved through synchronous replication, but achieving zero recovery time objective (RTO) has been a major bottleneck to achieving business continuity. Although synchronous copies of data were available, accessing those copies when needed required scripting, disruptive cutover procedures, and manual interventions.
SnapMirror active sync changed the game for SAN by offering zero RPO and zero RTO for block workloads. With ONTAP 9.19.1, that same synchronous replication with automated failover capability extends to NAS workloads, like NFS and SMB. This type of NAS data is often equally mission‑critical as SAN, but transparent failover was out of reach. If you run mission-critical file workloads on AFF or AFX, this release is worth a closer look.
In this post, you will see the gap SM-as NAS closes, how replication and failover behave under the hood, and where it fits next to other solutions offered by NetApp.
The problem: Business continuity for NAS lagged behind SAN
SnapMirror active sync has delivered zero-RPO, zero-RTO failover for SAN workloads for some time. Critical NAS data, like finance ledgers on SMB, Oracle or virtualization workloads on NFS, custom financial small file workloads, and mixed-protocol departmental shares, was also subject to strict regulatory and operational compliance requirements. The DR options for those workloads included MetroCluster for site-wide protection, using SnapMirror synchronous replication with a manual failover process, or simpler SVM-DR that could deliver a low RPO, but not zero RPO.
Those options involved trade-offs:
- MetroCluster excels when you need infrastructure-level, site-wide continuity. Still, it comes with architecture and operational constraints that not every file workload can tolerate, and it does not offer the granularity of SnapMirror active sync.
- SVM-DR is approachable for whole-SVM protection, yet asynchronous replication means data loss is possible at failover, and recovery is operator-driven.
- SM-as proved synchronous replication plus automated failover could work at metro distances, but NAS was out of scope until now.
Before 9.19.1, zero data loss and transparent application failover for these critical NAS workloads was offered with MetroCluster. Without it, customers had to compromise with disruptive procedures, RPO trade-offs, or SAN-only active sync while file services waited. From 9.19.1, critical FlexVol data within SVMs can be protected with zero-RPO, zero-RTO with transparent application failover, leveraging proven SnapMirror and SnapMirror active-sync technologies.
What’s new in ONTAP 9.19.1
SnapMirror active sync for NAS ships in ONTAP 9.19.1 and later. Supported platforms are AFF and AFX.
Table 1: SnapMirror active sync NAS vs SAN
Area | NAS (9.19.1+) | SAN |
|---|
Granularity | SVM | Consistency group |
Configuration | Active-passive with AutomatedFailover | Active-active or active-passive |
Protocols | NFS, SMB3 CA shares (non-disruptive failover)
Other SMB versions (disruptive failover) | iSCSI, FC, NVMe |
Note: Although the failover in SMB 2.x / SMB 3.x versions and non-CA shares is disruptive (remount/restart apps), the zero RPO for data is still maintained. This is a protocol limitation and not under the control of SnapMirror active sync.
Unlike SM-as SAN, NAS does not offer active-active client I/O on both sides of the same protected SVM during normal operation. The secondary SVM remains dormant until failover or planned failover.
How it works: architecture overview
1. Synchronous data replication: Protected FlexVol volumes in an SVM replicate data synchronously to the partner cluster. Writes are acknowledged to clients only after commit on both sides, which delivers zero RPO for protected volumes.
2. Configuration Replication Service (CRS): SVM configuration, i.e., LIF definitions, exports, shares, quota configuration, and related settings, are replicated so the secondary can assume the identity of the primary SVM during failover. Identity discard is not supported. You must plan your network environment carefully for matching network design on both sites.
3. ONTAP Mediator: The Mediator (on-premises Linux VM or NetApp Console hosted) is required. It provides quorum for cluster health decisions, enables automated failover, and helps prevent split-brain by ensuring only one site serves a given protected SVM relationship.
Figure 1: SnapMirror active sync NAS
Secondary SVM behavior
Failover does not rely on traditional LIF migration in the sense of moving addresses you never pre-staged. The CRS-replicated LIFs already exist on the secondary and transition to operational up/up on their home nodes.
Table 2: Secondary SVM behaviour
Attribute | Normal (secondary) | After failover (secondary) |
|---|
Subtype | dp-destination | default |
Operational state | stopped | running |
LIFs | up/down (admin state / operational state)
(no IP collision) | up/up (same IPs clients already use) |
Volumes | RW, not mounted | RW, mounted, serving I/O |
Granularity
Protection is SVM-scoped, but you can include or exclude individual volumes when creating the relationship, or when adding volumes later. You can seamlessly add or remove volumes from the SM-as relationship as and when the SLA changes. It does not delete the volumes or the data inside them; instead, internally, volume membership changes trigger a geometry expand or shrink operation.
Figure 2: Granularity of protection
Co-existence
SnapMirror active sync for SAN and NAS can run on the same cluster. It also allows protected and unprotected SVMs to coexist. To protect a NAS SVM with SnapMirror active sync, the SVM must be dedicated to NAS workloads and must not host SAN or object (S3) protocols.
Figure 3: Co-existence of SVMs
Async fan-out
SnapMirror active sync for NAS solves metro-distance, zero-RPO continuity between two sites. Many customers also require a 3-way DR solution with a third location, a remote vault, or a recovery region with asynchronous replication and different RPO/RTO expectations. In ONTAP 9.19.1, SM-as NAS supports volume-level async fan-out with one additional SnapMirror async leg per protected volume, layered on top of the synchronous SM-as relationship.
Figure 4: SnapMirror async fanout
Key benefits
- Zero-RPO: Synchronous replication for protected NAS FlexVols. No application data loss at failover for in-scope protocols.
- Zero-RTO with automated failover.
- Transparent failover where protocols allow, i.e., NFS and SMB3 CA clients can reconnect with no disruption.
- Granular, workload-level protection. Protect critical SVMs (or subsets of volumes within an SVM) without committing the entire cluster to a single DR model.
- Granular workload failover: Selectively fail over individual tenants, departments, or applications at SVM level without impacting the rest of the cluster. This enables targeted DR testing, non‑disruptive maintenance, phased migrations, and even active load balancing between sites.
- Unified operations story: Manage relationships through ONTAP System Manager alongside SM-as SAN; one ONTAP skillset for block and file metro continuity.
- Secondary copy utility: Cross-SVM FlexClone on the destination supports test/dev, analytics, and DR validation without impacting primary I/O.
- Cost-efficient metro DR: Uses a standard inter-cluster network without dedicated replication switches.
Use cases
- Enterprise file services with strict RPO/RTO requirements:
Departmental or business-specific SVMs that must survive site loss without replaying hours of file changes, especially where audit or compliance treats file data like tier-1 applications. - Financial services and healthcare:
Workloads that already demanded sync block DR can now align selected NAS tiers (e.g., document repositories, imaging interfaces on NFS, SMB CA–enabled application shares) to the same business continuity requirements provided protocol choices match non-disruptive vs disruptive failover expectations. - Manufacturing and design collaboration:
Project shares that need metro-distance protection and predictable failover without rebuilding every mount point. - Service providers and multi-tenant clusters:
SVM-level failover independence allows a protected SVM to fail over without forcing unrelated SVMs on the same cluster into the same event. This helps service providers and multi-tenant environments meet client-specific compliance or regulatory requirements by enabling workloads to run from the secondary cluster when needed. After failover, client access to protected volumes is served from the secondary cluster, providing greater flexibility in where data is accessed and hosted. - Phased Site Migration & Active Load Balancing
Gradually transition operations from one data center to another on an SVM-by-SVM basis for lower-risk migrations. Distribute active workloads optimally by running some enterprise applications on Site A and others on Site B, while protecting both.
Considerations and limitations
- Treat SM-as NAS as workload-granular continuity, not a wholesale MetroCluster replacement. MetroCluster remains the answer when you need site-wide, infrastructure-level protection.
- Scale (per HA pair): up to 50 NAS SVMs (combined with SAN CGs: 50 (SVMs + CGs) total), 400 volumes, 80 volumes per SVM, 16 LIFs per SVM.
- Replication topology: Two-way SM-as (each cluster hosts independent protected SVMs for the other) is supported to optimize infrastructure utilization.
- Auto reconfiguration of asynchronous replication fan-out leg, SVM-granular async fan-out, and cascade replication is not supported with SnapMirror active sync for NAS in the first release.
