Let’s get into it.

Granular Datastore Protection: Protect Only What Needs Protecting

The headline feature in 10.6 is Granular Datastore Protection (GDP), which shifts both SnapMirror active sync (SMas) and most traditional SnapMirror replication policies from only protecting entire host clusters down to individual VMFS datastores. Instead of protecting every datastore in a cluster whether it needs it or not, vCenter administrators can now choose exactly which datastores belong in a protection group — and add, remove, or delete them one at a time without disturbing the rest.

What is a protection group? It’s a vCenter-local representation of a consistency group (CG) in ONTAP 9 on AFF, ASA, FAS, and software-defined systems. We chose to use the term “protection group” in ONTAP tools to be aligned with VMware’s terminology. What this ultimately means is that you can now create and manage CGs directly in the vCenter UI.

So, what does this mean for new ONTAP tools users?

• Selective protection — mix protected and unprotected datastores freely within the same host cluster.
• Operational flexibility — modify protection groups without tearing down protection for an entire cluster.
• Multiple protection groups per cluster — replicate different datastores to different storage virtual machines (SVMs) or targets as business needs dictate.
• Incremental adoption — protect new datastores as they’re created, or bring existing ones into a group over time.

Ok, what if you are an existing user of ONTAP tools? It's simple — upgrades from ONTAP tools 10.4 and 10.5 seamlessly migrate existing host-cluster protection settings to the new model, no manual reconfiguration or import required.

GDP supports SnapMirror active sync's "Automated Failover Duplex (AFD)" policy across uniform and non-uniform vSphere Metro Storage Cluster (vMSC) topologies — giving architects far more precision when designing business continuity for mixed-criticality workloads. GDP can also use traditional asynchronous SnapMirror policies, though that would not be a vMSC configuration.

For a deep dive into GDP, check out the blog that Rajiv and I wrote about it: SnapMirror Active Sync + ONTAP tools for VMware vSphere Granular Datastore Protection (OTV10.6) - NetApp Community

A Lighter Footprint, Right Out of the Box

Not every environment needs a heavyweight appliance. ONTAP tools 10.6 introduces an Extra Small (XS) deployment size — just 6 vCPUs and 12 GB of RAM per node — and makes it the default Day-0 deployment profile for traditional provisioning and protection workloads. That’s a noticeable reduction from the previous Small footprint (9 vCPU / 18 GB), removing a resource barrier that had kept smaller environments and edge sites from adopting ONTAP tools.

Also new in this release, CPU hot add and memory hot plug are now enabled by default, so scaling up to small, medium, or large later requires no manual reconfiguration on fresh 10.6 deployments, nor do you have to shut down the appliance to reconfigure it if you forgot to do so during the initial deployment.

Stronger Security Visibility with Expanded Audit Logging

Security and compliance teams get a significant upgrade in 10.6. ONTAP tools now captures detailed audit logs (including full request and response bodies), discovery and cleanup jobs, and maintenance console operations — complete with username, timestamp, and correlation IDs for full traceability. Logs are retained for 30 days by default (configurable), protected by automated integrity checks that raise alerts on tampering or deletion, and can be forwarded to external systems like VCF Operations for Logsvia syslog. Enterprise security teams increasingly require this level of visibility. With ONTAP tools 10.6, it’s now built directly into the appliance.

Faster NFS Datastores with nconnect Support

NFS performance got a major boost with nconnect support back in 8.0u2. But it lacked any kind of GUI or API (I wrote a blog about it here: Automate nconnect and snapshot offload for NFS datastores and turn your VMware storage up to 11 - NetApp Community). It is now configurable directly during NFSv3 and NFSv4 datastore provisioning. By establishing multiple TCP connections over a single IP address, nconnect lets ESXi hosts distribute file operations across those connections in round-robin fashion — unlocking more of the available network bandwidth for NFS workloads without any change to the storage network topology. With nconnect, NFS datastores deliver SAN-level performance with NAS-level simplicity.

ONTAP tools 10.6 can even modify the maximum nconnect limit of your ESXi hosts from the default limit of 4 up to the maximum supported 8.

When it comes to nconnect integration, there is one caveat to be aware of: due to a limitation in the vCenter SDK, a plugin can’t modify nconnect settings after the datastore is mounted. However, starting with vSphere 9.0, you can change these settings in the datastore's host connectivity menu. Additionally, you can use the script that I shared earlier.

Cleaner Lifecycle Management

Even good old-fashioned housekeeping gets easier with ONTAP tools 10.6. A new force-delete flag for vCenter removal lets administrators clean up stale or unreachable vCenter entries — including automatic ONTAP tools plugin unregistration — without being blocked by lingering storage backend or datastore associations, provided no vVol datastores or active protection are involved.

Under the hood, ONTAP tools 10.6 also dynamically switches from ntpd to chronyd for time synchronization (with automatic migration on upgrade), re-implements and optimizes the authentication service for a smaller resource footprint and faster startup, and reorganizes log storage under a dedicated /var/log/otvng directory for cleaner troubleshooting and log rotation.

Availability

ONTAP Tools for VMware vSphere 10.6 launched on July 24, 2026, and supports ONTAP 9.16.1 through 9.19.1 alongside VMware Cloud Foundation (VCF) 5.2.1 through 9.0, and vSphere 8.0U3 through 9.0(the appliance can be deployed on ESXi 9.1). More version qualifications may be coming, so stay tuned for further updates. Direct upgrades are supported from ONTAP tools 10.4 and 10.5, with existing host-level protection settings automatically migrated to the new Granular Datastore Protection model.

In summary, whether you’re running a lean single-site deployment or a stretched, multi-site VMware environment protected by SnapMirror Active Sync, ONTAP tools 10.6 gives you finer control, a smaller footprint, and better visibility — all without compromising on the enterprise-grade protection NetApp customers count on.

Active-Active VM Storage at Datastore Granularity: SnapMirror Active Sync meets ONTAP tools Granular Datastore Protection 

The two things to remember 

1. Active-active with synchronous SnapMirror (SnapMirror active sync / SM-as) — ONTAP TOOLSONTAP tools Granular Datastore Protection (GDP) lets you hand-pick VMFS-FC or VMFS-iSCSI datastores inside an ESXi host cluster and protect them with zero recovery time objective (RTO)/zero recovery point objective (RPO)replication backed by ONTAP SnapMirror Active Sync. VMs can read and write from either site. 
2. Load balancing across sites: Workloads can actively use I/O from either location.  
3. With uniform host proximity, peered datastores at both sites are mapped to ESXi hosts at both sites. If one ONTAP cluster becomes unreachable, VMs continue serving I/O from the surviving site with typical failover latency on the order of ~11 ms (the actual I/O resumption time [IORT] will be environment-dependent).  
4. With non-uniform host proximity, ESXi hosts are only mapped to the local copy of the datastore. I.e. If a VM migrates or fails over to a host on the other site, that host only accesses the local ONTAP cluster. If one ONTAP cluster becomes unreachable, the VM will use vSphere HA to failover to the other site since it can only access its local copy.  

Everything else in this article explains how ONTAP tools 10.6 provisions and governs that experience. 

Why GDP changes the protection conversation 

Before ONTAP TOOLS 10.6, Host Cluster Protection (HCP) was all-or-nothing: protecting a cluster meant protecting every eligible VMFS datastore on that cluster together. 

Granular Datastore Protection (GDP) shifts the unit of protection from the host cluster to individual VMFS datastores — while still operating within a single ESXi host cluster boundary. 

Customer value: Protect only the datastores that matter, add/remove datastores over time, and run different SnapMirror targets per SVM, without forcing every datastore in the host cluster into the same protection group. 

What ONTAP SM-as brings to GDP 

SnapMirror Active Sync (SM-as) is ONTAP’s synchronous, active-active replication mode used by the Automated Failover Duplex (AFD) policy. Combined with GDP, it delivers: 

• RPO = 0 — writes are synchronously committed to NVRAM on both sites before acknowledgment 
• RTO = 0 — because both copies are always available, IO can resume as soon as the mediator initiates the failover and the host multipath driver can retry any required I/Os 
• Active-active data path — both copies are read/write capable (policy and proximity permitting) 
• Consistency group (CG) backed protection — multiple LUNs/datastores in one atomic replication unit 
• Automatic host access orchestration — ONTAP TOOLS manages igroups, LUN maps, mounts, and HBA rescans 

GDP is the ONTAP TOOLS control plane; SM-as is the ONTAP replication engine. ONTAP TOOLS creates and lifecycle-manages: 

• Protection Settings — which datastores are protected, CG membership, SnapMirror relationship 
• Cluster Configuration — fault domains, host-to-SVM mapping, uniform vs non-uniform proximity 
• Initiator groups (igroups) — host IQNs/WWPNs mapped to protected LUNs at each site 

ONTAP TOOLS 10.6 constructs that you configure 

1. Protection Setting 

A protection group ties together: 

• One or more VMFS datastores (same host cluster, same SVM) 
• An ONTAP consistency group 
• A SnapMirror Active Sync relationship (for AFD) 
• Initiator groups for host access 

Typical workflows: Protect · Modify (add/remove datastore) · Unprotect · Delete 

2. Cluster Configuration (required for AFD / SM-as) 

Maps an ESXi host cluster to two fault domains (Site A / Site B): 

• Each fault domain lists ESXi hosts + peered source/target SVMs 
• The uniform_host_config attribute is set at create time and is immutable 

The following table illustrates the two protection constructs. 

Prerequisite: Create Cluster Configuration before protecting datastores with AFD/SM-as. Async-only SnapMirror does not require cluster configuration. 

Uniform vs Non-Uniform Host Proximity 

This is the architectural fork that determines the system behavior during various modes of failure in different fault domains. 

Uniform proximity (uniform_host_config = true) 

Behavior: Peered datastores from both sites are mapped to ESXi hosts at both sites. All hosts in the cluster can access all protected datastores. ONTAP TOOLS manages igroup replication and host proximity settings across both SVMs. 

Use cases: 

• Active-active workload distribution — VMs on either site issue I/O to locally mapped LUNs based on proximity settings 
• Metro / stretched cluster — compute at both sites, storage synchronously mirrored 

How does GDP use SMas to protect you in different failure scenarios: 

• Storage cluster failure — IO continues without vSphere HA by using remote copy 
• Storage network failure on local target side of network — IO continues without requiring vSphere HA by using the remote copy 
• Storage network failure on local initiator side of network — A vSphere HA event triggers automatic recovery on the remote site with VM reboot 
• Compute failure — vSphere HA reboots VM on an applicable ESXi host based on resource availability. Affinity and anti-affinity rules may dictate which site the VM is rebooted on 
• Full site outage — VM’s on the failed site are rebooted and recovered by vSphere HA on the surviving site, and I/O is resumed; typical switchover latency ~11 ms (lab/field reference; actual depends on distance, network, and load) 

Non-uniform proximity (uniform_host_config = false) 

Behavior: Peered datastores are mapped only to hosts locally within each site. Site A hosts access Site A SVM LUNs; Site B hosts access Site B SVM LUNs. Replication is still synchronous (SM-as), but with a reduced number of non-disruptive failure scenarios at the VM layer. For this reason, uniform configurations are considered the best practice when the environment can support it. 

Use cases: 

• Campus / dual-room: each room’s hosts only access their local copy 
• Optimizing limited WAN bandwidth: eliminating host network traffic between failure domains 
• Reduced SAN path management: hosts cannot see remote paths 
• Sync DR with site affinity: zero data loss 

How does GDP use SMas to protect you in different failure scenarios: 

• Storage cluster failure — A vSphere HA event triggers automatic recovery on the remote site 
• Storage network failure on target side of network — A vSphere HA event triggers automatic recovery on the remote site 
• Storage network failure on initiator side of network — A vSphere HA event triggers automatic recovery on the remote site 
• Compute failure — vSphere HA reboots VM on applicable ESXi host based on resource availability. Affinity and anti-affinity rules may dictate which site the VM is rebooted on 
• Full site outage — VM’s on the failed site are recovered by vSphere HA on the surviving site, and I/O is resumed; typical switchover latency ~11 ms (lab/field reference; actual depends on distance, network, and load) 

Side-by-side comparison 

End-to-end user flow: from datastore selection to protected active-active 

GDP use cases (where customers win) 

Version and platform guardrails (ONTAP TOOLS 10.6) 

Supported 

Not supported in 10.6 

• NFS and NVMe datastore protection 
• Sync / strict-sync policies outside AFD SM-as scope 
• Local snapshot policies for GDP workflows 
• Protecting datastores across different SVMs in one protection setting 
• Moving a datastore between protection groups (unprotect + re-protect required) 
• Custom async SnapMirror policies 
• MetroCluster-backed configurations 
• ONTAP clusters with > 4 nodes 
• Mixing uniform and non-uniform protection on the same host cluster 
• Protection failover initiated from ONTAP TOOLS UI (use ONTAP System Manager) 
• ONTAP TOOLS discovering CGs / SnapMirror created outside ONTAP TOOLS (CLI/SM) 

Operational guardrails customers should know 

Host proximity and igroups — what ONTAP TOOLS automates 

When you protect a datastore, ONTAP TOOLS 10.6: 

1. Creates or extends an ONTAP consistency group spanning the protected LUNs/volumes 
2. Establishes SnapMirror Active Sync to the peered SVM 
3. Creates nested igroups (parent per datastore, child per host) with host IQNs/WWPNs from participating sites 
4. For uniform AFD: replicates igroups across sites so all hosts retain access 
5. For non-uniform AFD: creates site-local igroups mapped to local fault-domain hosts 
6. Mounts peer datastores and rescans HBAs when topology changes (cluster config modify) 

You do not manually patch igroups for GDP lifecycle operations — ONTAP TOOLS owns add/remove host, mount, unmount, and shrink flows. 

Deeper dive, what happens when a complete site or failure domain goes down? 

Uniform proximity + SM-as 

• Both copies were actively serving I/O 
• SM-as maintains synchronous consistency 
• ESXi hosts at the surviving site continue I/O on the accessible LUN paths 
• Expected: I/O continuity with failover latency typically in the ~11 ms range (not a guaranteed SLA — validate in your environment) 

Non-uniform proximity + SM-as 

• Source-site hosts were actively using local LUNs; target site held the sync replica 
• RPO remains 0 — no committed write loss 
• RTO is non-zero — DR-site hosts (or orchestrated failover) must establish access via igroup/mount/rescan workflows 
• ONTAP TOOLS cluster configuration modify / protection discovery may be needed after topology events 

Quick decision guide 

Summary 

ONTAP SnapMirror active sync provides the synchronous, active-active replication engine. ONTAP TOOLS 10.6 Granular Datastore Protection provides the VMware-native control plane to: 

• Hand-pick which VMFS datastores to protect inside a host cluster 
• Model uniform or non-uniform host proximity via Cluster Configuration 
• Lifecycle-manage consistency groups, SnapMirror, igroups, mounts, and rescans 

Key Takeaways  

Active-active sync SnapMirror: GDP + SM-as delivers zero-RPO, dual-site VMFS protection at datastore granularity. 

Load balancing: SnapMirror active sync enables both sites to actively serve I/O, maximizing resource utilization with best of breed business continuity on failure. 

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:

1. 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.
2. SVM-DR is approachable for whole-SVM protection, yet asynchronous replication means data loss is possible at failover, and recovery is operator-driven.
3. 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

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

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.

Databases are at the heart of many business‑critical applications and services. They underpin essential functions such as order processing, billing, inventory management, customer portals, analytics, and much more. When a database becomes unavailable, the consequences are immediate: users lose access to vital information, business operations are disrupted, and reputational damage can quickly ensue.

To ensure business continuity, organizations set strict recovery point objectives (RPO) and recovery time objectives (RTO) for their most critical databases. Having a backup alone isn’t enough; you must be able to restore swiftly to a recent point in time. Achieving these demanding recovery targets for self-managed databases on Amazon Web Services (AWS) becomes increasingly difficult as the environment expands in scale.

By using Amazon FSx for NetApp ONTAP as the backbone of your data infrastructure, you can optimize platforms such as SQL Server, Oracle DB, MongoDB, SAP HANA, and others. For many demanding workloads with strict SLAs, FSx for ONTAP is often the only service that enables these databases to run reliably and at scale on the AWS Cloud. In this post, I am going to explain how this is achieved.

Here’s what we’ll cover:

• Navigating database resilience challenges: Meeting strict objectives at scale on AWS
• How FSx for ONTAP optimizes resilience for self-managed databases
• What this means for your team: Benefits in practice
• Summary and next steps

Navigating database resilience challenges: Meeting strict objectives at scale on AWS

Protecting a single database is one thing, but the task changes dramatically when you’re responsible for a large-scale environment. A typical mission-critical deployment can involve hundreds of databases, several hundred terabytes or more of data, and multiple environments dedicated to development, testing, pre-production, and other purposes.

Within such a landscape, you must meet a range of requirements simultaneously: High availability to ensure that business-critical workloads withstand both component failures and disruptions to Availability Zones (AZs), strict backup recovery objectives, robust disaster recovery (DR) architecture to maintain business connectivity during major incidents, and diligent cost control given the significant expenses associated with database licences, compute resources, and storage capacity.

Traditional designs that rely solely on database-level replication and periodic backups to block storage or object storage often struggle to address all these demands at scale. As a result, backup windows can expand, restore processes might take longer, and disaster recovery deployments can become increasingly complex and costly to maintain.

How FSx for ONTAP optimizes resilience for self-managed databases

Let’s take a closer look at the standard architecture of self-managed databases on AWS and then discuss how FSx for ONTAP can optimize it. For this example, we will focus on a SQL Server.

Initial architecture: AOAG SQL Server running on Amazon EC2 and Amazon EBS

I recently worked with a financial customer managing hundreds of databases and over 500 TB of data across multiple environments, including development, test, pre-production, and others. This deployment required high availability across AZs, RPO of 10 minutes and RTO of 1 hour, and an effective DR site to protect against large-scale events and maintain business continuity. The following diagram illustrates the SQL Server architecture the customer chose, with Amazon Elastic Block Store (Amazon EBS)—a common solution for running a SQL Server on AWS:

In this design:

• Two Amazon Elastic Compute Cloud (Amazon EC2) instances running SQL Server are deployed in different AZs within an AWS Region.
• Each instance uses multiple Amazon EBS volumes for database files, log files, and other data.
• SQL Server replication, such as AOAG, keeps the databases synchronized between the instances.
• Amazon EBS snapshots are used for volume-level backups, with snapshot data stored in Amazon Simple Storage Service (Amazon S3).

This architecture delivers high availability by distributing SQL Server instances across two separate AZs, while ensuring data durability and recoverability through SQL-level replication and Amazon EBS snapshots stored in Amazon S3. It provides flexible scaling, clear separation of compute and storage, and protection against outages within the Region.

However, it has several implications:

• Licensing. AOAG often requires SQL Server Enterprise licensing, which can significantly increase costs when you have many cores and multiple replicas.
• Backup and restore times. As data volumes grow, the time required to create and restore from volume-level snapshots and copies increases. Meeting the 1-hour RTO across hundreds of databases becomes difficult.
• Storage and cost. Multiple Amazon EBS volumes, frequent snapshots, and long retention periods increase storage consumption.
• DR site. Building a DR site using this design typically involves additional infrastructure, extra replicas, more storage, and complex orchestration to meet the RPO and RTO targets.

At this stage, companies are seeking an alternative architecture to overcome these challenges and optimize resilience. In many cases, as was the case with this customer, the solution lies in the choice of storage service.

Optimized architecture: SQL Server FCI running on Amazon EC2 and FSx for ONTAP

Now let’s look at an architecture for a SQL Server failover cluster instance (FCI) using FSx for ONTAP as the underlying storage, which the abovementioned customer eventually moved to:

With this approach, backup and recovery workflows change. Instead of relying only on host-based backups, you use storage-level snapshots as the primary mechanism for protecting data. Creating a snapshot is a fast operation and restore workflows can be built around reverting or cloning from those snapshots.

Because FSx for ONTAP provides high availability across AZs, it can be used as a shared block storage for both Amazon EC2 instances. With this capability, the customer can move away from an AOAG architecture to FCI, while achieving the same or even better availability. For this architecture, a Standard SQL licence can be used, substantially reducing licensing costs.

Additionally, because this architecture requires only a single copy of data, it reduces storage capacity and costs and eliminates cross-AZ charges. And without the need for SQL-level replication, Amazon EC2 instance resources are freed up.

FSx for ONTAP backup operations are based on NetApp incremental Snapshot™ technology. Stored locally on the file system, These Snapshots are created rapidly, require minimal storage due to their space-efficient design, and enable quick recovery from logical failures. Their efficient use of space also keeps backup costs low and ensures performance remains unaffected during creation.

Thanks to an integrated free tool called NetApp SnapCenter® that synchronizes these Snapshot copies with the SQL Server, they become database-aware and require no log forwarding as part of the restoration process.

Adding disaster recovery to the mix

Now let’s add another layer of protection. To further safeguard against physical failures, the design extends to a secondary FSx for ONTAP file system, which can be air-gapped and deployed in another Region. Using NetApp SnapMirror®, data is replicated asynchronously and efficiently, ensuring the latest backups are always available for DR without the overhead of full data copies.

The following diagram shows the SQL Server DR architecture with FSx for ONTAP:

In this setup, the primary FSx for ONTAP file system replicates data incrementally and asynchronously to a secondary FSx for ONTAP file system in a separate Region, providing protection against site-wide or physical failures.

A disaster recovery SQL Server instance can swiftly attach to replicated volumes or space-efficient thin clones, enabling rapid failover and recovery. DR tests and failovers rely on these storage-level copies, eliminating the need for time-consuming full data restores.

This approach aligns easily with demanding recovery objectives, such as a 10-minute RPO and 1-hour RTO, because both replication and restoration are handled efficiently at the storage layer.

Outcomes of the revised architecture

Compared to the initial architecture, FSx for ONTAP streamlines resilience with high availability across AZs. Backup happens in seconds and restore in minutes, and an effective disaster recovery site is provided.

For the customer, this meant:

• Meeting its RPO and RTO requirements.
• Achieving high availability across AZs using a storage‑centric design.
• Reducing backup operations to seconds and restore operations to minutes by using application-aware, lightweight snapshots.
• Building an efficient DR site backed by storage replication.
• Transitioning to a SQL Server Failover Cluster Instance (FCI) design that provided an approximately 40% reduction in licensing and maintenance costs, along with additional savings on compute and storage.

What this means for your team: Benefits in practice

This strategy delivers significant benefits for teams managing their own databases on AWS.

Database administrators enjoy quicker and more reliable backup and restore processes, even when working with hundreds of databases. Regular testing of recovery and disaster recovery procedures becomes more straightforward, because snapshot-based clones allow for the rapid creation of temporary environments.

Storage administrators benefit from a solution built for efficient snapshots, thin clones, and replication—naturally supporting database protection. They can set storage policies once and apply them consistently across multiple databases and environments.

Cloud architects can implement an architecture that meets stringent RPO and RTO objectives, while optimizing licensing, compute, and storage expenses. Additionally, this approach makes it easier to scale as more databases, environments, and Regions are introduced.

In short, FSx for ONTAP empowers each team to focus on strategic improvements rather than routine maintenance, enhancing both productivity and resilience.

Summary and next steps

Protecting self‑managed databases on AWS at scale is challenging. You need high availability, fast recovery capabilities, and a robust DR strategy, while keeping an eye on cost and operational complexity.

By adopting FSx for ONTAP as the storage layer and optimizing the architecture, companies can meet strict SLA requirements, achieve high availability across AZs, build efficient DR sites, while gaining substantial savings on licensing costs and additional cost savings on compute and storage.

If you’re running self-managed databases on the AWS Cloud today, this architecture is worth evaluating. Start by assessing your current RPO and RTO targets, backup times, and disaster recovery design, and consider how FSx for ONTAP can help you protect your databases more efficiently.

To deepen your understanding and explore practical guidance:

• Watch the explainer demo video, showing 3.1 TB of SQL data backed up in just 9 seconds and restored in 8 minutes.
• Read about how FSx for ONTAP optimizes database performance and reduces costs by up to 50% and how to protect your SQL Server workloads using NetApp SnapCenter in our blogs.
• Check out the how-to guides and documentation to help you get started.

Organizations are continuously seeking ways to extract more value from their data while minimizing operational friction. Advanced analytics is one way that can happen.

Amazon Athena, a serverless interactive query service, has long enabled teams to analyze data stored in Amazon Simple Storage Service (Amazon S3) using standard SQL. But it’s not always easy to make file data stored in on-premises systems or outside of AWS accessible to Athena without carefully planned relocations to Amazon S3.

Now it’s possible to run Athena SQL queries directly on data stored in Amazon FSx for NetApp ONTAP (FSx for ONTAP) file systems, and a new world of possibilities is opening up for solution architects, data engineers, and IT leaders. This direct data access streamlines analytics, enhances data governance, and solves the long-standing challenges of data migration.

Read on as we cover:

• The challenges of migrating data to Amazon S3
• Direct SQL analytics with Athena on FSx for ONTAP
• The benefits of the FSx for ONTAP Athena integration
• Get your data to Athena without a migration

The challenges of migrating data to Amazon S3

In typical analytics workflows, preparing data for analysis with Athena would often mean moving datasets from enterprise storage systems into data lakes stored on Amazon S3. However, this data movement process could be time-consuming and require extra attention:

• Extract-transform-load (ETL) jobs: Data engineers must build, maintain, and monitor ETL pipelines, which require specialized skills and tools.

• Operational overhead: Data migration introduces latency, a risk of data inconsistency, and potential compliance issues due to storing data outside of on-premises data centers or specific regions.

• Resource costs: Duplicating large datasets consumes additional compute, network, and storage resources, driving up costs and slowing down project timelines.

These challenges can stall business insights and create friction between data producers and consumers.

Direct SQL analytics with Athena on FSx for ONTAP

With the new Amazon S3 Access Points for FSx for ONTAP capability, Amazon S3-based services can directly access file data stored in FSx for ONTAP using the Amazon S3 API. That means Athena can query data in your FSx for ONTAP volumes without migrating or duplicating data to Amazon S3. Data remains within the FSx for ONTAP file system, and users access it using familiar SQL syntax, just as they would with Amazon S3-based datasets.

This direct approach means analytics teams can easily run queries, generate reports, and build dashboards using the latest data, all while maintaining a single source of truth (SSoT).

Choosing FSx for ONTAP as the storage target for Athena delivers several advantages:

• Multiprotocol access: FSx for ONTAP supports Network File System (NFS), Server Message Block (SMB), and now Amazon S3 protocols. This means the same data can be accessed by analytics tools, legacy applications, and AWS-native services without duplicating files or managing multiple silos. Learn more about the FSx for ONTAP multiprotocol capability.

• Non-disruptive operation: FSx for ONTAP lets users query source data directly, eliminating the need to transfer or manipulate data for use on Amazon S3, reducing duplication and time delays. Athena can run live data, providing up-to-date insights without impacting your production applications.

• Extending on-premises deployments: With the help of NetApp® SnapMirror® data replication, on-premises ONTAP® users can easily replicate data to FSx for ONTAP for use with Athena. There’s no need for the ETL pipeline to get the data to Amazon S3, and the dataset is kept in sync seamlessly. 

• Advanced data management: Features such as point-in-time NetApp Snapshot™ copies and rapid cloning allow teams to create safe, instant backups and DevTest environments, accelerating data-driven development and recovery processes. Learn more about the FSx for ONTAP cloning capability.

• Data protection: FSx for ONTAP provides robust data protection through point-in-time Snapshot copies, and Autonomous Ransomware Protection (ARP), which automatically detects and mitigates ransomware threats. Business continuity is further enhanced by built-in data replication, enabling seamless backup and recovery across sites and AWS Regions, along with FSx for ONTAP cyber vault capabilities that secure critical backups in isolated environments for added resilience.

• Storage efficiency features: FSx for ONTAP offers built-in thin provisioning, data deduplication, compression, and compaction, as well as data tiering, all of which significantly reduce your storage footprint and its associated costs. Learn more about the FSx for ONTAP cost efficiency.

Deduplication also benefits performance when running analytics workloads on large volumes that contain similar or repetitive data.

The benefits of the FSx for ONTAP Athena integration

For cloud architects, data engineers, and IT leaders, the integration of Athena with FSx for ONTAP translates into real-world value:

• Flexibility: Multiprotocol access enables seamless collaboration between diverse teams and applications.

• Seamless access to on-premises data: With SnapMirror replicating data from ONTAP systems to FSx for ONTAP, Athena has seamless access to your datasets. No migrations required.

• Cost savings: Eliminating the need for data migration, the FSx for ONTAP storage efficiency features mean lower infrastructure bills and less time spent on operational tasks.

• Simplified workflows: With data available for both operational and analytical workloads in place, teams can move faster from raw data to actionable insights.

• Improved data governance: Maintaining a single, consistent copy of data simplifies access control, auditing, and meeting compliance goals. These are critical requirements for organizations in highly regulated sectors, such as the healthcare and financial industries.
  

Get your data to Athena without a migration

Running Athena queries directly on data stored in FSx for ONTAP is a gamechanger for organizations striving to modernize their analytics capabilities without the pain of migrating data to Amazon S3. 

This new accessibility brings together the best of both worlds: Instant, serverless SQL analysis and enterprise-grade storage with multiprotocol access, advanced data management, and storage efficiency. 

By adopting Athena with FSx for ONTAP, cloud architects, data engineers, and IT leaders can accelerate insights, reduce costs, and strengthen data governance empowering their teams to realize the full potential of their data, faster and more securely than ever before.

Learn more in:

• How Amazon S3 Access Points for FSx for ONTAP works
• Amazon S3 Access Points for FSx for ONTAP analytics use cases
• Amazon S3 Access Points for FSx for ONTAP documentation

Last week, NetApp previewed its new Backup and Recovery solution for Kubernetes-based containers, offering seamless, unified protection for applications on NetApp storage. This integration is a game-changer for those managing modern applications in their organizations.

Key Highlights:

• Unified Protection: Manage and protect Kubernetes applications and resources from a single console.
• Enhanced Data Protection: Leverages NetApp SnapMirror® for faster backups and restores, building on the robust Trident™ software.
• Streamlined Operations: Efficiently moves backup data to object storage using SnapMirror technology.

Preview features are:

• Centralized management for Kubernetes applications and resources.
• Structured incremental backups with protection policies.
• Restore applications to the same or different clusters and namespaces.
• Change block tracking for optimized performance.

Stay tuned for more features being added throughout the preview period!

In this blog post, we’ll guide you through setting up protection policies and protecting and restoring your K8s applications with NetApp backup & recovery.

Ready to elevate your data protection game? Let’s dive in!

Test environment

For our further demonstrations, we use an RKE2 cluster sks3725 with the latest version of the NetApp Trident CSI provisioner installed, and the NetApp ONTAP 9 simulator to provide backend storage.

After installing the RKE2 snapshot controller and configuring the Trident backend including the corresponding storage and volume snapshot class, we have this storage configuration on our cluster:

$ tridentctl -n trident get backends
+-----------------+----------------+--------------------------------------+--------+------------+---------+
|      NAME       | STORAGE DRIVER |                 UUID                 | STATE  | USER-STATE | VOLUMES |
+-----------------+----------------+--------------------------------------+--------+------------+---------+
| ontap-nas-vsim1 | ontap-nas      | 1654b6a5-b588-4d53-859d-20303c6d2f60 | online | normal     |       0 |
+-----------------+----------------+--------------------------------------+--------+------------+---------+

$ kubectl get sc
NAME                        PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
ontap-vsim1-nas (default)   csi.trident.netapp.io   Delete          Immediate           false                  18s


$ kubectl get volumesnapshotclass
NAME                    DRIVER                  DELETIONPOLICY   AGE
trident-snapshotclass   csi.trident.netapp.io   Delete           57s

For the backup and restore tests, we installed a simple Minio® application:

$ kubectl get all,pvc -n minio
NAME                               READY   STATUS    RESTARTS   AGE
pod/minio-b6b84f46c-sr2qm          1/1     Running   0          114s
pod/minio-console-cb99559c-zgq76   1/1     Running   0          114s
 
NAME                    TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
service/minio           ClusterIP   10.98.237.51   <none>        9000/TCP   115s
service/minio-console   ClusterIP   10.104.0.87    <none>        9090/TCP   115s
 
NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/minio           1/1     1            1           115s
deployment.apps/minio-console   1/1     1            1           115s
 
NAME                                     DESIRED   CURRENT   READY   AGE
replicaset.apps/minio-b6b84f46c          1         1         1       115s
replicaset.apps/minio-console-cb99559c   1         1         1       115s
 
NAME                          STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS      VOLUMEATTRIBUTESCLASS   AGE
persistentvolumeclaim/minio   Bound    pvc-b0fed8f1-c5ed-4000-b938-ba29393864f0   8Gi        RWO            ontap-vsim1-nas   <unset>                 116s

Our NetApp Backup and Recovery account and environment are prepared already as per the NetApp Backup and Recovery requirements: My user has the required permissions and a NetApp Backup and Recovery connector is already installed and configured in our on-premises test environment, and the working environment was created and associated with an Azure Storage account.

Discover the Kubernetes cluster

The typical workflow to protect your K8s applications obviously starts by adding your K8s cluster to NetApp Backup and Recovery, enabling you to then add applications to the cluster and protect the resources hosted by the cluster.

If you are discovering Kubernetes workloads for the first time, in NetApp Backup and Recovery, select Discover and Manage under the Kubernetes workload type. If you have already discovered Kubernetes workloads, in NetApp Backup and Recovery, select Inventory > Workloads and then select Discover resources.

In the next screen, select the Kubernetes workload type.

Enter the cluster name to add to NetApp Backup and Recovery and choose a NetApp Backup and Recovery connector to use with the K8s cluster:

Now NetApp Backup and Recovery creates command line instructions to add the K8s cluster to NetApp Backup and Recovery.

Follow the command line instructions on your K8s cluster:

$ kubectl create namespace trident-protect
namespace/trident-protect created

$ kubectl -n trident-protect create secret generic tp-proxy-api-token --from-literal apiToken=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhY2NvdW50X2lkIjoiN2YyOTU1YWItZDEwOS00NTk3LThkMzItMzM2M2NmOTVjYTllIiwiYWdlbnRfaWQiOiJjSFBTTFRWRzdXM1FKVnN0czJFSTRXazBUZmx5U2ZiVyIsImlhdCI6MTc1MjY4MTQ1M30.7PcaZ4VwnWCAhA137wV5lgH9cLHDTI8Ngzq9fut3vGY
secret/tp-proxy-api-token created

$ helm repo add --force-update netapp-trident-protect https://netapp.github.io/trident-protect-helm-chart
"netapp-trident-protect" has been added to your repositories

$ helm install trident-protect netapp-trident-protect/trident-protect-connector --version 100.2507.0 --namespace trident-protect --set clusterName=sks3725 --set trident-protect.cbs.accountID=7f2955ab-d109-4597-8d32-3363cf95ca9e --set trident-protect.cbs.connectorID=cHPSLTVG7W3QJVsts2EI4Wk0TflySfbWclients --set trident-protect.cbs.proxySecretName=tp-proxy-api-token --set trident-protect.cbs.proxyHost=http://10.192.65.83/tpproxy
NAME: trident-protect
LAST DEPLOYED: Wed Jul 16 18:10:16 2025
NAMESPACE: trident-protect
STATUS: deployed
REVISION: 1
TEST SUITE: None

These steps install Trident protect and the Trident protect connector on the K8s cluster in the trident-protect namespace, ensuring that NetApp Backup and Recovery can interact with the K8s cluster.

$ kubectl get all -n trident-protect
NAME                                                      READY   STATUS    RESTARTS      AGE
pod/trident-protect-connector-566f7c87cb-twc4b            1/1     Running   0             43s
pod/trident-protect-controller-manager-5cbf8b5f57-wpc4p   2/2     Running   1 (38s ago)   43s
 
NAME                                                         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
service/tp-webhook-service                                   ClusterIP   10.100.92.100    <none>        443/TCP    44s
service/trident-protect-controller-manager-metrics-service   ClusterIP   10.109.117.217   <none>        8443/TCP   44s
 
NAME                                                 READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/trident-protect-connector            1/1     1            1           44s
deployment.apps/trident-protect-controller-manager   1/1     1            1           44s
 
NAME                                                            DESIRED   CURRENT   READY   AGE
replicaset.apps/trident-protect-connector-566f7c87cb            1         1         1       44s
replicaset.apps/trident-protect-controller-manager-5cbf8b5f57   1         1         1       44s

After you complete the steps, select Discover. The cluster is added to the inventory.

Select View in the associated Kubernetes workload to see the list of applications, clusters, and namespaces for that workload. We see our newly added cluster sks3725 in the list of managed clusters:

Create application

With our test cluster sks3725 added to NetApp Backup and Recovery, we can now add our sample Minio application to NetApp Backup and Recovery, making NetApp Backup and Recovery aware of the running application on the Kubernetes cluster. In NetApp Backup and Recovery, select Inventory, then select the Applications tab and click on Create application.

Now add your name for the application, select the K8s cluster it’s running on, and the namespaces that contain the app’s resources. Optionally you can also include resources based on label and GroupVersionKind (GVK) filters and add cluster scoped resources to the NetApp Backup and Recovery application definition. In our case, we simply add the minio namespace to the application definition.

We now hit Search to get the list of application resources NetApp Backup and Recovery discovers and check the list for completeness.

In the next window, we could add pre- and postscripts (execution hooks the run before and after snapshots/backups) and assign a protection policy to the application. As we don’t need pre- and postscripts and want to create a protection policy separately, we skip both steps and create the application.

The minio application is created and appears in the list of applications in the Applications tab of the Kubernetes inventory with the protection status “Unprotected” and application status “Ready”.

Create protection policy

Next, let’s create a new protection policy. We start from the list of applications in the Backup & recovery Inventory, find our still unprotected minio application in the list of applications and select

Create protection policy

Next, let’s create a new protection policy. We start from the list of applications in the Backup & recovery Inventory, find our still unprotected minio application in the list of applications and select Protect from the associated Actions menu.

From there, we can create a new protection policy (or could add an existing one).

In the first step, we select Kubernetes as the workload type and set the policy name as pu-minio-11.

Then we select the backup architecture. As we want to protect our application also against for example the failure of the K8s cluster, the underlying ONTAP storage, or the whole data center, we select “Disk to object storage” as data flow model, which protects the application data by local snapshots and copies of the data in an offsite object storage.

Now we define the protection schedules, sticking with the default schedules of hourly snapshots and one daily snapshot, keeping the last three snapshots of each cycle.

Next, we select the object storage location to store the Kubernetes application resources during each snapshot cycle, selecting an already configured Azure backup target.

Then we select the object storage location to store the actual application backup data, in our case we use the same target as for the application resources.

In the last step, we can adjust the schedule for the backup schedules if needed and click Create to create the protection schedule.

Protect application

To protect our sample application, we go back to the list of applications in the Backup & recovery Inventory, select our minio application and select Protect from the associated Actions menu.

Now we search for the newly created protection policy pu-minio-11 in the list of existing policies and select it.

As we don’t want to add any pre- or postscript, we select Done and the policy is attached to the application.

NetApp Backup and Recovery now immediately starts a baseline backup, a full backup of the application. Any future incremental backups are created based on the schedule that you define in the protection policy associated with the application. We can track the progress of the backup by selecting Track progress.

This leads to the Monitoring tab, where we see the details of the protection job, which succeeds after a short while.

Checking on the K8s cluster with the Trident protect CLI, we see the baseline backup and snapshot.

$ tridentctl-protect get backup -n minio
+-------------------------------------+------------------+----------------+-----------+-------+--------+
|                NAME                 |       APP        | RECLAIM POLICY |   STATE   | ERROR |  AGE   |
+-------------------------------------+------------------+----------------+-----------+-------+--------+
| baseline-transfer-backup-9hviqxzflt | minio-bjo9nkv54p | Retain         | Completed |       | 16m26s |
+-------------------------------------+------------------+----------------+-----------+-------+--------+
$ tridentctl-protect get snapshot -n minio
+---------------------------------------------+------------------+----------------+-----------+-------+--------+
|                    NAME                     |       APP        | RECLAIM POLICY |   STATE   | ERROR |  AGE   |
+---------------------------------------------+------------------+----------------+-----------+-------+--------+
| backup-e97a09a2-7b1f-4296-b718-b8c3f648a29f | minio-bjo9nkv54p | Delete         | Completed |       | 16m35s |
+---------------------------------------------+------------------+----------------+-----------+-------+--------+

On-demand backup

We can also manually create a backup of the sample application if needed, for example to make sure the most recent data is protected. Again, from the list of application in the Inventory, select the minio application and select Backup now from the Actions menu.

Start the on-demand backup by selecting Back up.

The on-demand backup starts, and we could again track its progress.

Once the backup finishes, we can see it on the cluster listed as an ad-hoc backup.

$ tridentctl-protect get backup -n minio
+-------------------------------------+------------------+----------------+-----------+-------+-------+
|                NAME                 |       APP        | RECLAIM POLICY |   STATE   | ERROR |  AGE  |
+-------------------------------------+------------------+----------------+-----------+-------+-------+
| ad-hoc-backup-drpz2so916            | minio-bjo9nkv54p | Retain         | Completed |       | 2m8s  |
| baseline-transfer-backup-9hviqxzflt | minio-bjo9nkv54p | Retain         | Completed |       | 39m8s |
+-------------------------------------+------------------+----------------+-----------+-------+-------+

From View and restore in the Actions menu of our application, we can check the details of the application protection, and the list of available restore points.

We see three restore points, as meanwhile the schedule kicked in an created the first scheduled backup.

This can also be seen with the CLI, showing the three available backups and snapshots.

$ tridentctl-protect get backup -n minio
+-------------------------------------+------------------+----------------+-----------+-------+--------+
|                NAME                 |       APP        | RECLAIM POLICY |   STATE   | ERROR |  AGE   |
+-------------------------------------+------------------+----------------+-----------+-------+--------+
| ad-hoc-backup-drpz2so916            | minio-bjo9nkv54p | Retain         | Completed |       | 27m27s |
| baseline-transfer-backup-9hviqxzflt | minio-bjo9nkv54p | Retain         | Completed |       | 1h4m   |
| custom-eb7d6-20250724090012         | minio-bjo9nkv54p | Retain         | Completed |       | 12m28s |
+-------------------------------------+------------------+----------------+-----------+-------+--------+
$ tridentctl-protect get snapshot -n minio
+---------------------------------------------+------------------+----------------+-----------+-------+--------+
|                    NAME                     |       APP        | RECLAIM POLICY |   STATE   | ERROR |  AGE   |
+---------------------------------------------+------------------+----------------+-----------+-------+--------+
| backup-e2f70988-8b2e-4d6f-9ee0-332f186a8c72 | minio-bjo9nkv54p | Delete         | Completed |       | 27m30s |
| backup-e97a09a2-7b1f-4296-b718-b8c3f648a29f | minio-bjo9nkv54p | Delete         | Completed |       | 1h4m   |
| custom-eb7d6-20250724090012                 | minio-bjo9nkv54p | Delete         | Completed |       | 12m31s |
+---------------------------------------------+------------------+----------------+-----------+-------+--------+

Restore application

Now we’re all set to test a restore of the minio sample application. Out of the many possible restore (and failure) scenarios, let’s see in more detail how we can recover our application to another cluster in case of a failure of the original cluster hosting the application.

For a realistic test scenario, let’s first simulate a cluster failure by stopping the Trident protect connector on the cluster. We scale down the trident-protect-connector deployment to zero and wait for the associated pod to stop.

$ kubectl -n trident-protect scale deployment.apps/trident-protect-connector --replicas=0
deployment.apps/trident-protect-connector scaled
 
$ kubectl get all -n trident-protect
NAME                                                               READY   STATUS    RESTARTS   AGE
pod/autosupportbundle-5cdc2a2f-4317-4eed-9c59-6f98d3bf0727-k58xh   1/1     Running   0          9h
pod/trident-protect-controller-manager-78f47d8788-fnlqs            2/2     Running   0          25h
 
NAME                                                         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
service/tp-webhook-service                                   ClusterIP   10.102.57.222   <none>        443/TCP    25h
service/trident-protect-controller-manager-metrics-service   ClusterIP   10.103.73.197   <none>        8443/TCP   25h
 
NAME                                                 READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/trident-protect-connector            0/0     0            0           25h
deployment.apps/trident-protect-controller-manager   1/1     1            1           25h
 
NAME                                                            DESIRED   CURRENT   READY   AGE
replicaset.apps/trident-protect-connector-677554db48            0         0         0       25h
replicaset.apps/trident-protect-controller-manager-78f47d8788   1         1         1       25h
 
NAME                                                               STATUS    COMPLETIONS   DURATION   AGE
job.batch/autosupportbundle-5cdc2a2f-4317-4eed-9c59-6f98d3bf0727   Running   0/1           9h         9h

This leads to NetApp Backup and Recovery losing the communication to the K8s cluster. After some minutes, our cluster goes into the "Removed" state in NetApp Backup and Recovery.

Luckily our application is protected already, and we can easily initiate a restore to another cluster. We select again View and restore from the Actions menu of the minio application in the list of applications.

From the list of available restore points, we select the restore point from which we want to restore form and select Restore from its associated Actions menu.

As the local snapshots are not available anymore due to the cluster failure, we select to restore from object store and choose the destination cluster from the list of managed clusters.

We choose minio-dr as destination namespace on the destination cluster and select Next.

As we want to restore the complete application, we select Restore all resources and then Next.

Finally, we select to restore to the default storage class on the destination cluster and start the restore by selecting Restore.

We can also track the progress of the restore job, which finishes after some minutes.

Finally, we confirm that the minio application is up and running on the destination cluster in the minio-dr namespace.

$ kubectl get all,pvc -n minio-dr --context sks3794-admin@sks3794
NAME                               READY   STATUS             RESTARTS       AGE
pod/minio-b6b84f46c-v7cxw          1/1     Running            0              4h42m
pod/minio-console-cb99559c-td8f4   1/1     Running            0              4h42m
 
NAME                    TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
service/minio           ClusterIP   10.103.102.117   <none>        9000/TCP   4h42m
service/minio-console   ClusterIP   10.108.79.13     <none>        9090/TCP   4h42m
 
NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/minio           1/1     1            1           4h42m
deployment.apps/minio-console   1/1     1            1           4h42m
 
NAME                                     DESIRED   CURRENT   READY   AGE
replicaset.apps/minio-b6b84f46c          1         1         0       4h42m
replicaset.apps/minio-console-cb99559c   1         1         1       4h42m
 
NAME                          STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS      VOLUMEATTRIBUTESCLASS   AGE
persistentvolumeclaim/minio   Bound    pvc-d2bbdd4f-9fe1-4fa3-a89d-8c65264b400e   8Gi        RWO            ontap-vsim4-nas   <unset>                 4h42m

Conclusion and call to action

NetApp has introduced a preview of its NetApp Backup and Recovery solution for Kubernetes workloads, enhancing the protection of Kubernetes-based containers. This new solution offers a unified management console, leveraging NetApp SnapMirror for efficient backups and restores, and integrates seamlessly with NetApp Trident software for streamlined operations. Key features include centralized management, structured incremental backups, and the ability to restore applications across different clusters and namespaces.

This blog post provides a detailed guide on setting up protection policies, protecting, and restoring Kubernetes applications using NetApp Backup and Recovery. It includes step-by-step instructions for configuring the test environment, discovering Kubernetes clusters, creating applications, and implementing protection policies. Additionally, it covers manual and on-demand backups, as well as restoring applications to different clusters in case of failures.

Ready to elevate your data protection strategy? Dive into the comprehensive guide and start leveraging NetApp Backup and Recovery for your Kubernetes workloads today! Ensure your applications are protected against any failures with seamless, efficient, and unified backup solutions. Get started now and experience the future of data protection with NetApp Backup and Recovery!

Complete this form to gain access to the preview program. Upon completing the form, you'll gain access to the service and can start exploring its features and providing feedback within 48-72 hours. 

In today’s cloud-centric landscape, organizations rely heavily on data replication technologies to ensure business continuity, disaster recovery, and high availability. SnapMirror, a powerful data replication feature from NetApp, plays a vital role in replicating data across ONTAP environments — including AWS FSx for NetApp ONTAP (FSxN). But even the most robust replication strategy needs deep visibility and proactive monitoring to deliver true reliability. That’s where NetApp Data Infrastructure Insights comes into play.

The Challenge with Data Replication in the Cloud

SnapMirror is designed to efficiently replicate data between ONTAP systems, whether on-premises or in the cloud. With FSxN, you get all the benefits of ONTAP in a fully managed AWS service. However, as your cloud footprint grows and data volumes scale, it becomes increasingly difficult to track:

• The health of each replication relationship
• Lag times between source and destination
• Transfer efficiency and throughput
• Failover readiness

Traditional monitoring tools often lack granular insight into SnapMirror operations, especially across hybrid or cloud-native environments. This blind spot can lead to missed SLAs, data inconsistency, or recovery delays.

Enter NetApp Data Infrastructure Insights

NetApp Data Infrastructure Insights is a modern observability solution that delivers real-time visibility across hybrid cloud multi-vendor environments. By monitoring FSxN with Data Infrastructure Insights, you gain full-stack awareness of your SnapMirror relationships with powerful dashboards, proactive alerts, and historical analytics.

Key Benefits of Monitoring SnapMirror

1. Proactive Alerting for Replication Issues

Data Infrastructure Insights continuously monitors SnapMirror states — idle, transferring, broken-off, or failed — and triggers alerts when anomalies arise. This helps teams respond faster to issues before they impact recovery objectives.

2. Visualize Lag and Transfer Metrics

Track replication lag time in real-time, across all volumes and relationships. Dashboards make it easy to spot underperforming links or bottlenecks, helping you take corrective actions quickly.

3. Correlation with Infrastructure Metrics

Data Infrastructure Insights doesn't just stop at SnapMirror — it correlates replication performance with underlying FSxN storage health, network latency, and IOPS trends. This holistic view enables smarter troubleshooting and root cause analysis.

4. Simplified Compliance and Reporting

With built-in historical analysis and exportable reports, Data Infrastructure Insights helps document replication SLAs and demonstrate recovery readiness — a must for audits, compliance, and disaster recovery planning.

5. Scalable Insights for Hybrid and Multi-Cloud

Whether you're replicating from on-prem ONTAP to FSxN, or FSxN to FSxN across regions, Data Infrastructure Insights provides a single pane of glass to monitor it all. This unified visibility is essential for modern, distributed data architectures.

Final Thoughts

As cloud adoption accelerates, ensuring the reliability and performance of data replication is more critical than ever. Monitoring SnapMirror with Data Infrastructure Insights empowers teams to move from reactive to proactive operations — improving data resilience, reducing downtime, and enhancing operational confidence.

Ready to get started?

Reach out to your NetApp representative or request a demo to learn how you can integrate FSxN visibility into your observability strategy.

Hello Experts,

We are preparing to upgrade to 8.1.1 7-mode. All of our SAS disks need disk firmware upgrade, so I downloaded X412_S15K7560A15.zip.

inside /etc/disk_fw I see X412_S15K7560A15.lod.

I know have to to turn this on "options raid.background_disk_fw_update.enable"

I can access \etc\disk_fw via CIFS.

Should I move the  X412_S15K7560A15.zip inside \etc/disk_fw and then unzip inside OR

unzip X412_S15K7560A15.zip in a Windows machine and then copy-paste inside \etc\disk_fw?

Both steps would overwrite the existing LOD file, correct?

Or am I approaching this all wrong?

Thanks,

Maico

The landscape of modern game development is evolving rapidly and becoming more complex than ever before. Studios are pushing creative and technical boundaries to deliver increasingly rich and immersive player experiences. However, this evolution brings significant infrastructure challenges. Managing sprawling codebases, massive libraries of high-fidelity assets, lengthy compile and build times, and coordinating distributed teams worldwide place enormous strain on the development pipeline.

Compounding these technical challenges are security concerns, especially when working with external partners, and the high financial costs of maintaining robust, high-performance infrastructure. Traditional on-premises environments struggle to keep pace. They lack the elasticity, automation, and scalability that today’s demanding workflows require. Moreover, shortages in IT resources, scarcity of skilled personnel, and global supply chain disruptions make on-premises infrastructure maintenance increasingly impractical.

This reality has driven a significant shift: game studios are moving to the cloud

Cloud platforms—particularly AWS—offer a vast array of innovation-enabling services, built-in resiliency, and the ability to dynamically scale compute and storage resources based on fluctuating developer and player demand. This shift unlocks opportunities to optimize game development end-to-end: improving performance, enabling seamless collaboration, and drastically reducing time to market.

But to truly harness the cloud’s potential, game studios need more than just scalable compute—they require a cloud-native file system that delivers enterprise-grade performance, security, and data management capabilities that they experienced with on-prem infrastructure.

Game Studios are Building with Amazon FSx for NetApp ONTAP

Amazon FSx for NetApp ONTAP is a fully managed AWS service that integrates AWS’s scalable infrastructure with NetApp’s industry-leading ONTAP file system delivered as a native AWS service just like AWS’s other native data storage services. It is purpose-built to empower developers to streamline and accelerate their entire development pipeline—from asset ingestion and code management to build automation and playtesting. Additionally, it can directly tackle core infrastructure challenges in game development, enabling studios to innovate faster, scale smarter, and reduce costs, which is a perfect fit for game development.

In this blog, we'll explore:

• The unique challenges of game development in the cloud.
• How Amazon FSx for NetApp ONTAP addresses these through real-world use cases:
• Game code repositories: How AAA studios use FSxN with Perforce Helix Core (P4).
• Game build pipeline hydration: How FSxN accelerates build hydration and reduces costs.
• Developer Virtual Desktop Infrastructure (VDI): How FSxN enhances workspace provisioning efficiency.

• Manual deployment via AWS Console
• Automation using the AWS Cloud Game Development Toolkit
• Advanced workload management with NetApp BlueXP Workload Factory

Bridging the DevOps Gap in Game Development with FSx for NetApp ONTAP

Traditional software development benefits from mature DevOps workflows supported by toolchains like Jenkins, GitHub Actions, Gradle, and Webpack. These tools thrive on standardized, repeatable cycles with large active communities.

Game development, however, operates on a different scale and complexity. Massive codebases and vast asset libraries are typically managed via Perforce P4, a version control system designed for scalability and performance. Once developers submit changes, continuous integration and delivery (CI/CD) systems trigger automated build and test processes that rely on ephemeral build agents. These agents spin up with the necessary tools, execute jobs, and terminate upon completion.

The build artifacts in game development—compiled code, 3D models, audio files, textures—are enormous and complex. Testing often extends beyond automation to include human playtesting, adding further resource demands. Unlike standard software, games target multiple platforms simultaneously—PC, consoles, mobile—requiring resilient, high-throughput infrastructure capable of handling massive workloads without bottlenecks or failure.

This complexity creates a DevOps gap—both on-prem and traditional cloud data infrastructure often cannot efficiently support the performance, cost, and flexibility demands of game development pipelines.

Amazon FSx for NetApp ONTAP is purpose-built to addresses this gap in the cloud for game development by providing:

• High throughput and low latency: Accelerate build pipelines by delivering shared storage that supports fast, concurrent access to instant thin clones of code depots across distributed build agents.
• Cost savings: The combination of advanced deduplication and thin cloning reduce data duplication and storage footprint for build pipeline hydration, yielding up to 70% savings on infrastructure spend.
• Data protection: Native snapshotting and cross-region replication improve backup and disaster recovery capabilities while greatly improving data resilience and availability for game data with native high-available architectures.
• Simplified management: Centralized control and consistency across applications and platforms reduce operational complexity.
• Global collaboration: FSx for ONTAP supports distributed teams by delivering high-performance, consistent, and centralized data access across multiple locations ensuring the data developers crave is where they need it when they need it.
• Scalability and automation: Flexible and elastic infrastructure that grows with your project demands, reducing operational overhead and can be automated via extensive and easily accessible APIs.

For game studios specifically, FSx for ONTAP becomes a strategic enabler—helping close the tooling gap while aligning infrastructure with the creative and technical realities of modern game production. To do this, FSx for ONTAP leverages:

• Unique Instantaneous Thin Cloning: Create writable, point-in-time copies of datasets instantly without full data duplication, ideal for test environments or rapid iteration. For game builds, this means creating near-instantaneous, space-efficient copies of large game builds and asset libraries, drastically reducing storage costs and eliminating unnecessary data duplication.
• Deduplication & Compression: Reduce redundant data storage and optimize disk usage.
• Enterprise Grade Data Protection
• Snapshots & Backup: Instant, space-efficient point-in-time copies support rapid recovery.
• Resiliency and security: Built-in snapshotting, replication, and cross-region capabilities protect your most valuable assets and minimize downtime.

Together, these capabilities significantly streamline game development pipelines by enabling faster iteration, lowering costs, and enhancing code protection. By reducing end-to-end build and test cycles from hours to minutes, teams can accelerate time-to-market and improve Mean Time To Resolution (MTTR), allowing for quicker, more frequent, and higher-quality releases. Advanced cloning and data efficiency technologies help cut storage costs by up to 70%, boosting return on investment (ROI) and lowering total cost of ownership (TCO). Meanwhile, robust security and resiliency features protect critical intellectual property, ensuring rapid recovery and minimal downtime in the event of a failure.

This can all be realized in three strategically targeted aspects of the complete game development pipeline:

1. Game Code and Data Version Control Repositories
2. Game Build Pipeline Hydration
3. Game Developer VDI Workspace Provisioning

It's clear, game development is evolving - here's how some of the world's leading game studios are rethinking and optimizing core aspects of their game development pipelines with FSx for ONTAP at the center:

Use Case 1: Optimizing Game Code Repositories with FSx for NetApp ONTAP

When considering the game development process as a whole, creating and building a game starts with an idea made into code. Eventually, some of these games become core to critical success at their game studios necessitating the use of optimized solutions to manage the life of their award winning titles. Perforce P4 (formerly known as Helix Core) is the industry-standard version control system for game development, favored for its ability to handle massive critical codebases and complex branching workflows.

According to a 2023 TechValidate survey:

• 80% agree P4 is the most scalable, high-performance version control system
• 82% rate Helix Core’s scalability as "Best in Class" or "Significantly Better" than alternatives
• 100% reported ROI within 1-2 years of deployment

One of the major benefits of using Perforce P4 is its performance. P4 only preserves changes of updates in text files. For binary files, it compresses each version and saves them as chunks, known as versioned files. Even when a large development project increases the number of files or commits, the size of the repository (hxdepot) is not prone to explode. It also has a mechanism that works faster even if clients are physically away from the master server. Therefore, Perforce is used for version controlling not only text files, but also large binary files, such as images.

Modernizing P4 infrastructure by migrating these repositories and workspaces to the cloud is a natural step—but it brings challenges around cost, resiliency, and data flexibility due to the sheer size of game development data.

FSx for ONTAP extends the realized benefits of on-prem enterprise storage to Perforce P4 in AWS, enabling:

Flexibility, Scalability, and Elasticity as a well-architected AWS native service, FSx for ONTAP filesystems can be easily deployed in multiple flexible architectures for multiple P4 server types, scaled-out up to 72GBps of throughput, 2,400,000 IOPS, and ~1PB for a single namespace.

P4 on FSx for ONTAP HA Single-AZ

P4 deployed on FSx for ONTAP HA Multi-AZ

Furthermore, FSx for ONTAP can be easily and quickly adjusted to expand storage, throughput, and IOPS from within the AWS console, AWS and ONTAP CLI’s, various available APIs, or other available tools we’ll visit later in this article.

Up to 70% reduction in recurring storage costs via data deduplication, compression, compaction, and strategically leveraging FSx for ONTAP’s instant thin cloning in build processes. These efficiencies are maintained when leveraging FSx for ONTAP backups and replication for data protection. Data tiering can also be enabled for disaster recovery replicas that are infrequently used, even further reducing total data footprint.

Cross-AZ Data Footprint Reduction

Enhanced data protection and resiliency with improved RPO (Recovery Point Objective) and RTO (Recovery Time Objective) ensuring rapid recovery from failures or data corruption through:

• Flexible High Availability: Both Single-AZ and Multi-AZ deployments feature an HA pair of nodes that make a single filesystem. Single-AZ is a 2-node cluster in a single AZ and protects against a node failure in a single AZ. Multi-AZ is a 2-node cluster spread across 2 AZs and further protects from a single AZ failure.
• Advanced Snapshot Technology: Fast, space-efficient point-in-time backups which are also integrated into AWS and FSx Backups.
• Optimized Disaster Recovery: Cross-region replication (commonly known as SnapMirror on FSx for ONTAP), backups through integration with AWS and FSx Backup, and data tiering capability to balance cost and speed by tiering cold data to a cheaper and lower class storage medium.

P4 on FSx for ONTAP HA Multi-AZ replicating to P4 Edge/Replica on FSx for ONTAP HA Single-AZ leveraging data tiering for further cost reduction.

Global availability and consistency supporting distributed teams with centralized control. Since FSx for ONTAP is a native AWS service, it is consistently available in multiple AWS regions capable of supporting multiple Perforce P4 server types and replication across all regions where FSx for ONTAP is available.

P4 Global Availability on FSx for ONTAP

Critical high performance, low latency, and high throughput that game development hungers for. AAA studios have demonstrated significant performance gains by running Perforce on FSx for ONTAP in AWS by reducing latency and accelerating developer productivity while cutting infrastructure costs.

To achieve the highest performance possible, iSCSI (block storage protocol) on FSx for ONTAP for all P4 server volumes (/hxmetadata, /hxlogs, and /hxdepots) is considered the best practice. However, NFS can also be considered for the /hxdepots volume as a balanced performance vs. manageability option.

For a brief perspective on iSCSI vs. NFS performance differences, please consider the following analysis that leveraged Perforce’s general P4 multi-sync benchmark while testing multi-P4 client simultaneous multi-syncs:

P4 Multi-Sync Benchmark Total Client Throughput

P4 Multi-Sync Benchmark Total Client IOPS

For simultaneous multi-syncs up to 20 clients, the completion time was significantly better with iSCSI (block) storage. As we increased the number of clients to 150, the completion time was determined by network throughput, that is, the actual time it takes to pull the files into local client workspaces. In this case, iSCSI continued to outperform NFS with consistency.

However, regardless of which protocol is chosen for the /hxdepots volume, it is recommended to run multiple iSCSI or NFS nconnect sessions to achieve higher levels of throughput. This allows data to be transferred in parallel over multiple connections, thereby increasing the aggregate bandwidth and reducing the time it takes to complete I/O-intensive operations such as P4 syncs and submits. For example, the following configuration was used for the NFS testing shown above:

-o nfsvers=3,nconnect=8,local_lock=all
-n node.session.nr_sessions -v 8

Use Case 2: Accelerating Game Build Pipeline Hydration and Full Optimization

Hydrating build pipelines means populating the build environment with the latest game code and assets after changes are committed—critical for generating up-to-date builds for development, testing, and release.

Because game assets and build artifacts can reach terabytes in size, hydration can become a major bottleneck for game development studios. Copying large datasets consumes time and storage, slowing iteration and inflating costs.

FSx for ONTAP’s shared, high-throughput storage solves these problems by:

• Providing thin, instantaneous, and fully writable environments based on instant snapshots for rapid and cost effective provisioning.
• Creating new build environments in seconds with near-zero capacity overhead.
• Reducing build pipeline costs by up to 70% through thin cloning and data efficiency.

This results in:

• Faster build times and shorter MTTR.
• Enhanced collaboration with immediate access to the latest builds.
• Drastically lower infrastructure costs.

An award-winning AAA game development studio conducted its own analysis on cost savings between their current game build hydration configuration that leverages EBS vs. FSx for ONTAP leveraging their own game data for three distinct projects and achieved the following savings for Game Build Hydration with FSx for ONTAP:

Across three of their major game development projects, 80% storage savings was realized which translated to 68.3% in cost savings with FSx for ONTAP thin clones for build hydration.

While these cost savings are already drastic, FSx for ONTAP could be leveraged across the whole pipeline to reap further cost savings outside of just the build hydration portion of the pipeline as shown in the following sample architecture:

Ephemeral Game Build Hydration with FSx for NetApp ONTAP

Here's how the sample architecture for optimizing the game build pipeline works:

1. Build Trigger & Environment Provisioning
   A build is triggered either manually via a Self-Service Portal or automatically via Perforce or code flag. Orchestration (e.g., Jenkins, TeamCity, Ansible, Terraform, Horde) provisions build nodes using a custom AMI (built with Packer) that includes all necessary tooling (e.g., .NET SDK, msbuild, compilers, gcc, etc.). 

2. "Syncer" Client Selection & Preparation
   Orchestration monitors persistent lightweight instances called “Syncer” clients, which maintain replicated Perforce (P4) data from the Build-Edge. Each "Syncer" represents a unique workspace/changelist and mounts its primary volume from FSx for ONTAP, allowing persistent high-performance access and instant thin-clone capability. Once an available "Syncer" is found, it is synced to the latest requested changelist, enabling near-instant readiness due to the already-updated replica from Build-Edge.

3. Volume Cloning for Build Execution
   After the "Syncer" is updated, which only requires delta change updates, orchestration clones its volume using FSx for ONTAP thin clones, tied to the specific changelist. This clone is mounted to the already instantiated build node, providing access to the exact source code snapshot. Builds may read/write to this volume with minimal overhead due to snapshot-based delta management.

4. Post-Build Output & Distribution
   Build artifacts are written to S3 + CloudFront or back to FSx for ONTAP, depending on whether the use case involves developer collaboration (caching and testing), intermediate asset reuse, or external distribution to consumer platforms.

5. Teardown & Reset for Next Build
   Once the build is complete the builders are destroyed, their FSx for ONTAP clones are deleted, and the persistent "Syncer" clients remain, but are updated with the latest P4 data and reset for the next changelist request.

→ This cycle repeats efficiently for every new build request.

As shown, leveraging instant thin clones on FSx for ONTAP vs. other data services results in a drastic cost savings by reducing data requirements in the game build pipeline. Furthermore, because there is less data to copy, build hydration is significantly faster drastically reducing game builds.

Use Case 3: Optimizing Developer VDI Environments

Developers often require isolated Virtual Desktop Infrastructure (VDI) workspaces provisioned with the latest code and assets. Even further, these VDI workspaces need to travel with the developer, meaning the data needs to be globally mobile and consistent across regions. Traditional approaches use full snapshots, resulting in enormous data duplication and slow workspace creation.

Much like Build Hydration, because VDI orchestration would leverage similar code and instant thin cloning, FSx for ONTAP enables:

• Accelerated iteration: Workspace cloning from base volumes with FlexClone technology.
• Massive cost savings: Reduce copies from thousands of FULL snapshots to a handful of thin cloned volumes.
• Faster time to productivity: Reduces provisioning times from hours to minutes since FSx for ONTAPs cloning is a unique thin-provisioned cloning technology.
• Performance advantages: Provisioned file system-level performance outperforms individually provisioned native volumes.

Similar to Game Build Hydration, FSx for ONTAP's cloning capabilities can be used to reduce the storage footprint of workspace clones, game install volumes, user shares, or any other volume mount that needs to be ephemeral, mobile, and mounted to a dev VDI.

A major AAA game studio analyzed that they would benefit from $4.4M of savings annually for their developer VDI farm and would expect to multiply these savings as their developer base grows by leveraging FSx for ONTAP cloning concepts. They reported:

• Drastic reduction in storage footprint.
• Near-instantaneous code updates via cloning and FlexCache, a native ONTAP feature for efficient caching at distance.
• Significant cost savings and operational efficiency.

How to Get Started

AWS Console Manual Deployment

Amazon FSx for NetApp ONTAP is a native AWS service, available directly through the AWS Management Console alongside other native storage options like S3 and EBS. This provides a simple way to deploy, configure, and monitor your FSx file systems.

AWS Cloud Game Development Toolkit (CGD Toolkit)

The CGD Toolkit is a modular collection of templates, automation scripts, and reference architectures designed to streamline game infrastructure deployments on AWS. The toolkit provides

• Guidance: Recommendations and best practices for common architectures and tooling, from Packer to Horde and even managing iSCSI on FSx for NetApp ONTAP.
• Assets: Individual playbooks, pipelines, and automation scripts for targeted tasks.
• Modules: Reusable Terraform configurations for deploying workloads.
• Samples: Complete reference architectures combining modules and AWS services.

For example, studios can utilize provided customizable Terraform and Ansible templates, purpose built with best practices, to deploy Perforce P4 on FSx for ONTAP using the CGD Toolkit automation, drastically simplifying deployment and setup of not only P4 and it's associated infrastructure, but also required FSx for ONTAP iSCSI storage as recommended previously in this blog.

Basically, turn this:

Into this:

module "unreal_horde" {
  source                                = "modules/unreal/horde"
  unreal_horde_service_subnets          = aws_subnet.private_subnets[*].id
  unreal_horde_external_alb_subnets     = aws_subnet.public_subnets[*].id   # External ALB used by developers
  unreal_horde_internal_alb_subnets     = aws_subnet.private_subnets[*].id  # Internal ALB used by agents
  vpc_id                                = aws_vpc.unreal_horde_vpc.id
  certificate_arn                       = aws_acm_certificate.unreal_horde.arn
  github_credentials_secret_arn         = var.github_credentials_secret_arn
  tags                                  = local.tags

  fully_qualified_domain_name = "https://horde.${var.root_domain_name}"
}

resource "netapp-ontap_lun" "depots_volume_lun" {
  count           = var.storage_type == "FSxN" && var.protocol == "ISCSI" ? 1 : 0
  cx_profile_name = "aws"
  os_type         = "linux"
  size            = var.depot_volume_size * 0.75 * 1073741824
  svm_name        = var.fsxn_svm_name
  volume_name     = aws_fsx_ontap_volume.depot[0].name
  name            = "/vol/${aws_fsx_ontap_volume.depot[0].name}/${aws_fsx_ontap_volume.depot[0].name}"
  depends_on = [
    aws_lambda_function.lambda_function,
    aws_vpc_security_group_egress_rule.link_outbound_fsxn,
    aws_vpc_security_group_ingress_rule.fsxn_inbound_link
  ]
}

resource "netapp-ontap_san_lun-map" "depots_lun_map" {
  count           = var.storage_type == "FSxN" && var.protocol == "ISCSI" ? 1 : 0
  cx_profile_name = "aws"
  svm = {
    name = var.fsxn_svm_name
  }
  lun = {
    name = netapp-ontap_lun.depots_volume_lun[count.index].name
  }
  igroup = {
    name = netapp-ontap_san_igroup.perforce_igroup[count.index].name
  }
  depends_on = [
    aws_lambda_function.lambda_function,
    aws_vpc_security_group_egress_rule.link_outbound_fsxn,
    aws_vpc_security_group_ingress_rule.fsxn_inbound_link
  ]
}

**Disclaimer** The above snippets are only examples taken from:  https://github.com/aws-games/cloud-game-development-toolkit/tree/main/modules/unreal/horde & https://github.com/aws-games/cloud-game-development-toolkit/tree/main/modules/perforce/

For more complete and comprehensive code with guidance, please visit the AWS CGD Toolkit here:

https://aws-games.github.io/cloud-game-development-toolkit/latest/

NetApp BlueXP Workload Factory

BlueXP Workload Factory automates workload lifecycle management on FSx for ONTAP—handling everything from initial design to ongoing operations with workload-centric, best-practice workflows. For Perforce workloads, you can create and mount clones of desired game versions for QA or release from directly within the Perforce P4 client itself. Code snippets are automatically generated of the automation used to create and mount the clones which can be leveraged later in automated build pipelines.

Workload Factory accelerates the creation and management of software version data infrastructure, by leveraging FSx for ONTAP's thin cloning as mentioned previously. It eliminates the need for custom tools or scripts and seamlessly integrates with your CI/CD workflows including a built-in integration with Perforce P4 (Helix Core).

This allows you to more easily speed up development lifecycles, lower cloud spend, and increase developer productivity, making it easier to :

• Automate data cloning for software versions: Workload Factory facilitates the cloning of FSx for ONTAP-based data environments without the need for third-party tools or scripts. Developers can instantly create and access required software versions environments.
• Integrate cloning into CI/CD: Workload Factory seamlessly fits into existing CI/CD workflows by offering a well-documented API, as well as an out-of-the -box integration with Perforce P4 (Helix Core).
• Leverage Built-in administrations: Workload Factory simplifies administrational tasks of each software environment including automatic environment space reclamation, capacity limitations, and access duration.
• Establish workspace data control and audit: With Workload Factory, you gain the ability to effectively manage access policies for project’s data, monitor data usage, and audit user activity.

Get started with Workload Factory here: https://console.workloads.netapp.com 

In Conclusion

Amazon FSx for NetApp ONTAP and AWS together provide a comprehensive, scalable, and cost-efficient platform tailored for the unique needs of modern game development. From managing massive game code repositories and accelerating build pipelines to enabling agile developer environments, FSx for ONTAP empowers studios to innovate faster and deliver richer player experiences.

By bridging the DevOps gap between traditional software and game development, FSx for ONTAP helps studios reduce costs, improve resilience, and accelerate time-to-market—ultimately fueling creativity and success in an increasingly competitive industry.

Written by @LuisRico  and @Rahul-Rana

OpenShift Virtualization Disaster Recovery with NetApp Trident protect

• Introduction
• Red Hat OpenShift Virtualization
• Kubernetes lacks Disaster Recovery
• VMware SRM gap
• RTO and RPO requirements
• Requirements
• Source Cluster Setup:
• Destination Cluster Setup:
• Testing Disaster Recovery - Failover without affecting the source region
• Swapping the Regions - Migration of Virtual Machines
• Complete Disaster Recovery - Failover and Failback

Introduction

Red Hat OpenShift Virtualization 

Red Hat OpenShift Virtualization provides a virtualization platform on top of OpenShift to run and manage Windows and Linux Virtual Machines (VMs) alongside containers, by using Kubernetes custom resources to enable virtualization common tasks. 

It’s based on the open-source project KubeVirt that has become one of the most popular and active projects of the CNCF (Cloud Native Computing Foundation). 

Although the KubeVirt project started in 2017, it has only gained real popularity as an alternative virtualization platform in recent years. 

For running VMs in OpenShift Virtualization in production, the worker nodes of the OpenShift cluster must be bare metal servers, to avoid nested virtualization. Despite that fact you can run it on premises and on the main hyperscalers.  

Kubernetes lacks Disaster Recovery 

As OpenShift Virtualization runs on Kubernetes platform it intrinsically inherits the limitations of Kubernetes and OpenShift to usual practices performed by virtualization administrators. Kubernetes lacks Disaster Recovery (DR) tools, and so does OpenShift Virtualization.  

VMware SRM gap 

For VMware vSphere users, used to different DR applications included VMware Site Recovery Manager (SRM), it's a must to have a data protection tool with Disaster Recovery capabilities. For protecting hundreds or thousands of Virtual Machines with their VM disks, the only feasible option is to use some kind of storage replication to optimize the data transfer between sites. 

RTO and RPO requirements 

In the virtualization world, it's also usual to comply with strict Service Level Agreements (SLAs) on availability for the VMs, reflected on low RPO (Recovery Point Objective) and RTO (Recovery Time Objective). That forces the use of fast and efficient storage replication to transfer data as fast and frequent as possible for low RPO, and to automate the failover to reduce the time the VMs get started in the secondary/destination site for low RTO. 

NetApp with Trident Protect, that is available for NetApp customers at no additional cost with NetApp Trident, helps to solve this gap. 

Requirements 

Virtual Machine running on source OCP Cluster: 

ONTAP - Storage backends must be peered as mentioned in our documentation. 

AppVault – AppVault (Object Storage Bucket) is used to store metadata (k8s resources) for the Virtual Machine and associated namespace used during failover operations. Recommendation is to create two separate AppVault configurations for your source and destination sites. 

Source Cluster Setup: 

Cluster AppVault -  Verify that the AppVault CR shared between the source and destination has been created, following the example provided below. 

oc create secret generic <secret-name> \ 
--from-literal=accessKeyID=<objectstorage-accesskey> \ 
--from-literal=secretAccessKey=<ontap-s3-trident-protect-src-bucket-secret> \ 
-n trident-protect 

apiVersion: protect.trident.netapp.io/v1 
kind: AppVault 
metadata: 
  name: ontap-s3-trident-protect-src-bucket 
  namespace: trident-protect 
spec: 
  dataMoverPasswordSecretRef: my-optional-data-mover-secret 
  providerType: OntapS3 
  providerConfig: 
    s3: 
      bucketName: trident-protect-src-bucket 
      endpoint: s3.example.com 
      proxyURL: http://10.1.1.1:3128 
  providerCredentials: 
    accessKeyID: 
      valueFromSecret: 
        key: accessKeyID 
        name: s3-secret 
    secretAccessKey: 
      valueFromSecret: 
        key: secretAccessKey 
        name: s3-secret 

Create AppVault CR using command below: 

oc apply –f example-file.yaml 

Application CR - The Application CR is a Kubernetes object that allows Trident Protect to discover and manage user provided namespace or multiple namespaces for data protection operations, such as snapshots, backups, restores, or replication. 

 Define CR for your source application using example below: 

apiVersion: protect.trident.netapp.io/v1 
kind: Application 
metadata: 
  annotations: 
    protect.trident.netapp.io/skip-vm-freeze: "false" 
  name: demo-vm 
  namespace: source-vm-ns 
spec: 
  includedNamespaces: 
    - namespace: source-vm-ns 
      labelSelector: 
        matchLabels: 
          app: demo-vm 
  includedClusterScopedResources: 
    - groupVersionKind: 
        group: rbac.authorization.k8s.io 
        kind: ClusterRole 
        version: v1 
      labelSelector: 
        matchLabels: 
          mylabel: test

Create App CR using command below: 

oc apply –f example-file.yaml

Snapshot Schedule CR - Snapshot CR is used to specify the frequency (e.g., hourly) and retention (e.g., keep 24 snapshots) for data protection. These snapshots are then used for App Replication from source to destination OCP cluster. 

Snapshot Schedule - Schedule for snapshots (CR) using example below: 

apiVersion: protect.trident.netapp.io/v1 
kind: Schedule 
metadata: 
  name: snapshot-schedule 
  namespace: source-vm-ns  
spec: 
  appVaultRef: source-bucket 
  applicationRef: source-vm-ns 
  backupRetention: "0" 
  enabled: true 
  granularity: custom 
  recurrenceRule: |- 
    DTSTART:20220101T000200Z 
    RRULE:FREQ=MINUTELY;INTERVAL=5 
  snapshotRetention: "5" 

Create SnapshotSchedule CR using command below: 

oc apply –f example-file.yaml 

Destination Cluster Setup: 

Destination Cluster AppVault CR: Create a common  AppVault between source and destination so that destination cluster can access the application metadata created on the source cluster. Also create a destination AppVault similar to what was done on the source cluster.  

Configuring AMR 
 

AppMirrorRelationship CR: The AppMirror CR in NetApp Trident Protect is used to manage the replication frequency of applications across OCP clusters for disaster recovery and application mobility, leveraging NetApp’s SnapMirror technology. It defines the replication relationship between a source application and a destination, enabling failover, failback, or workload migration between OCP clusters. 

Define the application mirror relationship with a replication schedule. 

Example of AMR CR:  

apiVersion: protect.trident.netapp.io/v1 
kind: AppMirrorRelationship 
metadata: 
  name: amr-demo 
  namespace: destination-vm-ns 
spec: 
  desiredState: Established 
  destinationAppVaultRef: destination-bucket 
  namespaceMapping: 
    - destination:  destination-vm-ns 
      source:  source-vm-ns 
  recurrenceRule: |- 
    DTSTART:20220101T000200Z 
    RRULE:FREQ=MINUTELY;INTERVAL=5 
  sourceAppVaultRef: source-bucket-appvault 
  sourceApplicationName:  source-vm-ns 
  sourceApplicationUID: 7498d32c-328e-4ddd-9029-122540866aeb 
  storageClassName: ontap-sc 

Create AMR CR using command below: 

oc apply –f example-file.yaml 

As we can see below our AMR has been established and Region B namespace only contains the PVC 

Production Site Region A and Standby Site Region B 

Testing Disaster Recovery - Failover without affecting the source region

In this section we perform disaster recovery without impacting the our production site Region A. Towards the end we will bring down the VMs running in Region B without affecting our original site which is Region A.  In a failover scenario, the standby system or environment takes over the responsibilities of the primary system or environment, ensuring business continuity.

Failover without affecting the source region. 

Execute Failover on Region B: 

oc patch amr -n destination-vm-ns amr-demo --type='json' -p '[{"op": "replace", "path": "/spec/desiredState", "value":"Promoted"}]' 

You can observe AMR status change from promoting to promoted 

oc get amr amr-demo -n destination-vm-ns -w 

VM is up and running on Region B after failover 

Execute command below to discard changes on Region B cluster and re-establish mirror relationship from Region A to Region B: 

oc patch amr -n destination-vm-ns amr-demo --type='json' -p '[{"op": "replace", "path": "/spec/desiredState", "value":"Established"}]' 

Ensure AMR state change has changed from establishing to established 

oc get amr amr-demo –n destination-vm-ns -w 

We can see below AMR is back in Established state and VM has been Terminated 

Swapping the Regions - Migration of Virtual Machines

In this section Region B becomes the source region, and the Region A becomes the destination. Modifications to Region B Virtual Machines during failover are preserved.

Swapping Production and Standby Site

Prerequisite to this section of Reverse resync would be a failed over replication relationship as outlined above.

Delete AMR CR on Region B

oc delete amr amr-demo -n destination-vm-ns 

Capture changes since failover: Create a new base snapshot on Region B using example snapshot CR below: 

apiVersion: protect.trident.netapp.io/v1 
kind: Snapshot 
metadata: 
  namespace: destination-vm-ns 
  name: snapshot-cr 
spec: 
  applicationRef: destination-vm-ns 
  appVaultRef: Destination-bucket 
  reclaimPolicy: Delete 

 
Create Snapshot CR using command below: 

oc apply –f example-file.yaml 

Create snapshot schedule: Create a new snapshot schedule CR on Region B. 

apiVersion: protect.trident.netapp.io/v1 
kind: Schedule 
metadata: 
  name: snapshot-schedule 
  namespace: destination-vm-ns 
spec: 
  appVaultRef: destination-bucket 
  applicationRef: destination-vm-ns 
  backupRetention: "0" 
  enabled: true 
  granularity: custom 
  recurrenceRule: |- 
    DTSTART:20220101T000200Z 
    RRULE:FREQ=MINUTELY;INTERVAL=5 
  snapshotRetention: "5" 

Create SnapshotSchedule CR using command below: 

oc apply –f example-file.yaml 

Delete snapshot schedule on Region A 

oc delete schedule vm-snap-schedule -n source-vm-ns 

 Create new AMR CR: Establish a new AppMirrorRelationship CR on Region A. 

• Ensure namespace mapping is accurate 
• Ensure AppVaults have been swapped if using a source and destination app vault (destination will become source and source will become destination) 
• Ensure srcApplicationName matches the name of the Application CR created on secondary instance 
• Ensure srcApplicationUID matches the .metadata.uid from the Application CR created on the secondary instance

Example of AMR CR to be created on Region B OCP Cluster which can be created using: 

apiVersion: protect.trident.netapp.io/v1 
kind: AppMirrorRelationship 
metadata: 
  name: amr-demo 
  namespace: destination-vm-ns 
spec: 
  desiredState: Established 
  destinationAppVaultRef:  destination-bucket 
  namespaceMapping: 
    - destination:  destination-vm-ns 
      source:  source-vm-ns 
  recurrenceRule: |- 
    DTSTART:20220101T000200Z 
    RRULE:FREQ=MINUTELY;INTERVAL=5 
  sourceAppVaultRef: source-bucket-appvault 
  sourceApplicationName:  source-vm-ns 
  sourceApplicationUID: 7498d32c-328e-4ddd-9029-122540866aeb 
  storageClassName: ontap-sc 

Create AMR CR using command below: 

oc apply –f example-file.yaml 

Wait for AMR establishment: Wait for the AppMirrorRelationship to reach the "Established" state in Region A. 

oc get amr amr-demo -n source-vm-ns -w  

We can see below AMR is in the Established state in Region A 

Note: If VM was in running state it would be torn down as part of Establishing the AMR 

Region B is now the primary site with the VM operational replicating to Region A. 

Complete Disaster Recovery - Failover and Failback

In this scenario we revert to the original replication direction and state, we first replicate (resynchronize) any application changes to the Region A Virtual Machines prior to reversing the replication direction.

Syncing changes back to original Region A and bringing the App down on Region B 

Reversing the replication direction from Region B to Region A 

Prerequisite to this section would be Reverse resync a failed over replication relationship as outlined above.

Disable Schedules on Region B - Delete any snapshot schedules in Region B.

oc delete schedule snapshot-schedule -n destination-vm-ns 

ShutdownSnapshot CR: Create a ShutdownSnapshot CR on Region B to take a final snapshot and gracefully shutdown your application.  

Configure the following attributes for ShutDown snapshot CR: 

Region B AppVaultRef: (Required) This value must match the metadata.name field of the AppVault for the source application 

Region B ApplicationRef: (Required) This value must match the metadata.name field of the source application CR file.

Example of ShutdownSnapshot CR: 

apiVersion: protect.trident.netapp.io/v1 
kind: ShutdownSnapshot 
metadata: 
  name: replication-shutdown-snapshot 
  namespace: destination-vm-ns 
spec: 
  appVaultRef: destination-bucket 
  applicationRef: destination-vm-ns 

Create ShutdownSnapshot CR using command below: 

oc apply –f example-file.yaml 

On the source cluster, after the shutdown snapshot completes, get the status of the shutdown snapshot: 

oc get shutdownsnapshot -n source-vm-ns <shutdown_snapshot_name> -o yaml 

Shutdown snapshot created and VM resources have cleaned up in Region B

 After the ShutdownSnapshot has completed, get the name of the snapshot from the CR status as mentioned in our documention. 

On the source cluster, find the value of shutdownsnapshot.status.appArchivePath using the command below, and record the last part of the file path (also called the basename; this will be everything after the last slash): 

oc get shutdownsnapshot -n source-vm-ns <shutdown_snapshot_name> -o jsonpath='{.status.appArchivePath}' 

Perform a Failover using the snapshot basename in apparchive path retrieved using previous step from Region B to Region A. 

Follow Reverse Resync steps from Region A to Region B. 

Enable snapshot schedules on your original site Region A as described in prerequisites section of the blog. 

At this point you have completed the full cycle of failover and failback. VMs are again running in Region A replicating to Region B. 

Conclusion 
In conclusion, the integration of OpenShift Virtualization, NetApp Trident, and AppMirror provides a powerful solution for protecting and mirroring critical applications. By leveraging this integrated solution, organizations can unlock enterprise-grade virtualization, simplify management, and improve data protection. Whether you're a seasoned IT professional or just starting to explore the world of virtualization, this integrated solution is definitely worth considering. 

> version NetApp Release 9.15.1P5

1. I have a snapmirror relationship and I manually mirrored a snapshot "test5" from source to destination using the below command.

Dest > snapmirror -update -destination-path <> -snapshot test5

2. I created a flexclone at the destination using the snapshot test5

> vol clone show
Parent Parent Parent Vserver FlexClone Vserver Volume Snapshot State Type
------- ------------- ------- ------------- -------------------- --------- ----
dest     vol_dest_clone     dest         vol_dest          test5         online            RW

3. Now, I deleted(accidentally) the test5 snapshot at the source forcefully
*> snap delete -vserver source -volume vola -snapshot test5 -ignore-owners true

4. The snapmirror relationship is not affected by this even after an update:
>snapmirror update -destination-path dest:vol_dest
> snapmirror show
Progress Source Destination Mirror Relationship Total Last Path Type Path State Status Progress Healthy Updated -
---------- ---- ------------ ------- -------------- --------- ------- --------
SourceLocal:vola XDP dest:vol_dest Snapmirrored Idle - true -

Question:
- From the past experience I have noted that this type of action affects the snapmirror relationship. As mentioned in a 3rd party article:

~~~
If a FlexClone volume is created from a Snapshot copy that is not the most recent Snapshot copy, and that Snapshot copy no longer exists on the source volume, then every update will need to delete the Snapshot copy on the destination. In this case, all SnapMirror updates to the destination volume fail until the clone is destroyed or split.
~~
What has changed on a newer version of Netapp that deleting the source snapshot does not affect snapmirror?
Or it only affects if snapshot deleted is a baseline snapshot?

In 7-Mode I could stop snapmirror with

snapmirror off

How is this acheived in CDOT?

Going down into the node level there is the option

snapmirror.enable

But it doesn't seem to make a difference if it is on or off at this point.

Can anyone advise?

Good day,

With SVM Disaster Recovery I have 2 questions:

1) Is synchronous snapmirror supported?

2) Can you  failover a single volume from the SVM or it is only meant in SVM level recovery?

Thanks

Kathy

Hi All,

I am new to this platform, One of my snapshot size is kept on increasing and now it has consumed all the snap reserve space by taking spill. I wonder if this can cause any damage to snapshot or should I need to allocate more space to snapshot reserve. If is it so how to do that? Will it effect my volume?

For failed disks that still can be unfailed we use disk sanitization for wiping out any data before we return the disk to NetApp. To use disk sanitization we had to activate the option "licensed_feature.disk_sanitization.enable". After activation, this option can't be deactivated anymore. This is clearly documented in the command reference of the option.

In contrast to this the documentation of the sanitazation is very vague in regard to the consequences: "Attention: After disk sanitization is enabled on a storage system, it is permanent, and it prevents certain Data ONTAP commands from being run." (Storage Management Guide) We had to painfully learn that one of the commands that is prevented from being run is the vol move command. Before activating the option we used vol move without problems. Afterwards it threw an error message saying that vol move requires a Snapmirror license now.

In a case opened for this it was pointed out that this was for security reasons. Since we do not use Snapmirror we didn't have a licence and had to procure it. After adding the license vol move worked fine again. This occured with 7-Mode ONTAP 8.1.3 and I requested a documentation update on this. But it hasn't been incorporated in 8.3.1 yet.

Question:
Are there any experiences on what doesn't work in conesquence of activating the disk sanitization option?

Dear Experts,

I am new to this Community and I am looking for some steps on how to create a SnapMirror ( Site to Site Replication) both our Sites Identical Replica of AFF700 with 9.3 P1 running on it and we are using it as a Unified Array ( Block & File ) 

Appreciate any help or any technical kb article that shows the procedure. 

Thank You 

Storage Professional 

Hi Everyone,

I want to upgrade DataOntap in  7-mode . I want to stop snapmirror before upgrade and after upgrade again start it .

What is the best way to stop the snapmirror just for limited time  . i dont want to loose any snapshot or something happen for snapmirror relationships .

Thanks

What is snap vault?what is the difference between Snap mirror and snap vault?

I am unable to increase size of a filer. It's throwing an alert

'Volume has the fixed filesystem size option set '..

Hi,

I've lately come across this volume that I want to delete on my ClusterMode controller (8.3.1).

Volume is offline. I've tried "volume delete -vserver <SVM> -volume <VOL>" and received the following error:

Command Failed: Volume VOL in vserver SVM is in one or more SnapMirror relationships. You must delete the SnapMirror relationships before you can delete this volume.

However, there are no snapmirror relationships connected to this volume. I've checked it with "snapmirror list-destination -source-path SVM:VOL" and "snapmirror show -source-path SVM:VOL" and the output for both is There are no entries matching your query.

How can I delete my volume with nonexistent snapmirror relationships?

Hello,

There is an issue where we are unable to remove an SVM peer relationship so we can destroy the SVM.

The SVM is peered:

praesdc1    praesdc2    peered       dc2-tier1-cluster1

                                                       snapmirror     praesdc2

When trying to delete the peer relationship we get the following error "Error: command failed: Relationship is in use by SnapMirror iocal cluster. Use the "Snapmirror list-destinations" command to view the relationship"

Checking we do not see a Snapmirror relationship. I have been advised that the volumes were deleted before the relationship was broken.

Is there any way be can break the peer relationship when we dont see a Snapmirror relationship

Thanks

Two FAS 8020, NetApp Release 9.1P6 with SVM DR configured. When a volume gets created on Site A SVM it then gets automatically replicated to Site B SVM. Site B SVM is not running until failover. A few other things happend in a WFA workflow but that is basically what is going on.

I need to delete a few volumes but cannot because they are in a SVM DR relationship. When I attempt quiese, break or release a volume I get the message,  "Error: command failed: Cannot complete the operation because the destination volume "VOLUMES" belongs to Vserver "SVM" which is configured as the destination endpoint of Vserver DR relationship."

I can exclude a volume from SVM DR with this command, 

source_cluster::> volume modify -vserver vs1 -volume test_vol1 -vserver-dr-protection unprotected.

This will remove the relationship from System Manager but if you run list destination from the command line it still appears that relics of relationship are still present. Interesting enough, I can delete the destination volume but not the source volume. It it gives a similar message to the one above. Here is the message.

Data ONTAP API Failed: Volume "VolumeName" in Vserver "SVM" is the source endpoint of one or more SnapMirror relationships. Before you delete the volume, you must release the source information of the SnapMirror relationships using "snapmirror release". To display the destinations to be used in the "snapmirror release" commands, use the "snapmirror list-destinations -source-vserver SVM -source-volume Volume" command.

I have attempted the suggested commands and that is where I find the relics of the relationship even though I have excluded it from protection. I also can not doing anything on volume and will received the message above.

Support suggest I break the entire SVM DR relationship, then I will be able to interact with the volumes and eventually delete them. This seems excessive. Plus, while I am deleting the volumes, my other volumes are syncing on their scheduled interval.

Any suggestions?  

Hi -  i  am running OnTap cDOT 9.1P7.

I need to gather information for every snapmirror transfer which has completed and is still in the logs. I want to generate a single text file with the following fields

RelaionshipID:Start timestamp:FinishTimeStamp:TransferSize:TransferStatus

There are many logs and i can't seem to find any clear 'Start' and 'End' in the logs

Can anyone help me identify these fields so I can write some code to extract the data?

Thanks!

Hi all,

Does anybody knows how many cluster peer relationships I can have for one cluster (CDOT 8.3.1)? Which limit is if I will use SVM peering? I could not find a clear answer.

Thanks in advance.

P.S.
Yes, I've read the TR-4015

Hi All,

Need to replicate data between 2 data centers . we have AF series and FAS series and both are Ontap 9.X version.

below are the plan , Appreciate for help

1) Network route to be opened?

2)Open port 10566 for snap mirror replication. Any other ports to be opened?

3) Do we need perform cluster and SVM  peering ? before or after initiating snapmirror? Any firewall ports to be opened?

thanks

A few years ago, a colleague created a PowerShell script to throttle active SnapMirror jobs during business hours, and a separate script to unthrottle them at night. The scripts only apply to jobs that run into daytime hours and in some cases continue into a second day. We have to throttle during business hours or it brings these offices to a crawl.

We are about to convert the filers at our remote offices from 7-mode to cdot. Unfortunately, the "snapmirror throttle" command we use in 7-mode doesn't have an equivalent in cdot. i'm looking online and in help to determine the best way to accomplish the same task in cdot. Everything I've found so far adjusts throttling for the next transfer but not the current one. Any ideas?

Here is an example of the script we use for 7-mode:

Invoke-NaSsh -Name <filer_name> -Command "snapmirror throttle <amount> <destination_path>"

I have snapcenter plug-in for VMware and the underlying protocol is FC for the storage connectivity. 

I want to retain more snapcenter snapshots at the secondary storage and hence planning to use “mirror-vault” policy for SM relation and update snapvault after back up option in plugin. 

To restore a VM from vault backup what is the connectivity requirement from secondary storage to snapcenter plugin/vcenter/host. Do I need any fc connectivity as primary is based on FC protocol ?

we are migrating from one cluster to another and using SVM snapmirror config to perform the same, in this process the root volume migrated is having the naming convention of source netapp cluster, can I modify this in destination cluster. Will it have any impact?

I am trying to recreate a snapmirror policy with schedule that I built out manually on a test cluster.  Cluster is running ONTAP 9.12 and my toolkit is 9.12.1.2302.

My issue is when I try to apply the schedule (Cron Job) to the policy. When using the gui to build everything, I have no issues.  Below is my syntax:
"New-NcSnapmirrorPolicy -Name 45DailyBackup -Type async -SnapmirrorLabel backup -VserverContext $cluster -CreateSnapshotOnSource $false -Keep 45 -TransferSchedule MAAG-Vault"

 The error I get is (Cannot bind parameter 'TransferSchedule'. Cannot convert the "MAAG-Vault" value of type "System.String" to type "DataONTAP.C.Types.SnapmirrorPolicy.TransferSchedule".)
I have tried to assign the "Trasnfer Schedule" as a variable to see if it would convert, but no luck. However, I can use the gui and assign this transfer schedule. I also made an attempt to also use Set-NcSnapmirrorPolicyRule and Add-NcSnapmirrorPolicyRule using my Policy name, but I get "no matching records". Any help would be great as I feel I am missing something simple.