NetApp Disaster Recovery is a cloud-based disaster recovery service, accessed through the NetApp Console, that automates disaster recovery workflows for VMware and Kubernetes environments. It replicates on-premises VMware workloads running ONTAP storage, or Kubernetes workloads running Trident-managed ONTAP storage, to another site as a disaster recovery target. The service uses ONTAP SnapMirror technology, with native VMware orchestration or Trident Protect orchestration, to protect workloads while preserving ONTAP storage efficiencies such as compression and deduplication.

Disaster Recovery doesn't require any separate enablement. It automatically appears in the NetApp Console left navigation under Protection > Disaster recovery. To access the NetApp Console, in a browser, enter: https://console.netapp.com/.

A Disaster Recovery license is required for full, ongoing access. You can try the service with a 30-day free trial before purchasing a license or subscription. For details, refer to Set up Disaster Recovery licensing.

Disaster Recovery supports the following protection targets:

For VMware workloads, Disaster Recovery supports the following datastore types:

For Kubernetes workloads, Disaster Recovery protects persistent volumes provisioned through NetApp Trident on ONTAP storage.

Disaster Recovery offers the following licensing options:

Disaster Recovery charges are based on the used capacity of datastores on the source site when there is at least one VM or Kubernetes resource that has a replication plan.

For a BYOL, if the data exceeds the allowed capacity, operations in the service are limited until you obtain an additional capacity license or upgrade the license in the NetApp Console.

After the free trial ends, you can still view and delete resources such as workloads and replication plans, and run all scheduled operations that were created during the trial period. To continue using the service with full functionality, you need to obtain either a PAYGO subscription from your cloud provider or purchase a BYOL license from NetApp.

You can purchase a license or subscribe at any time and won't be charged until the 30-day trial ends.

Disaster Recovery supports the following topologies:

For the full list, see Disaster Recovery prerequisites.

A Console agent is a software component that enables the NetApp Console to communicate with your ONTAP storage and VMware vCenter clusters. It's required for Disaster Recovery to function properly. The agent resides in your private network (either an on-premises data center or a cloud VPC) and communicates with your ONTAP storage instances and vCenter clusters.

For on-premises to on-premises disaster recovery, install the on-premises Console agent in the disaster recovery site. For on-premises to AWS, install the Console agent for AWS in your AWS VPC. Both the source and destination vCenter clusters should use the same Console agent. Disaster Recovery works only with the standard mode agent deployment.

Each Kubernetes cluster must have NetApp Trident installed, an ONTAP backend and storage class configured, and the volume snapshot CRDs and controller installed. Applications must use persistent volumes provisioned through the Trident storage class. When you add a Kubernetes cluster as a site, Disaster Recovery guides you through installing and registering Trident Protect on that cluster. See Kubernetes cluster requirements for Disaster Recovery for step-by-step commands and verification checks.

A site is a logical container, typically associated with a physical data center or cloud location, that hosts one or more vCenter clusters or Kubernetes clusters. You add both a source (production) site and a destination (disaster recovery) site before creating a replication plan.

A resource group is a logical container that lets you manage multiple VMs, datastores, or Kubernetes namespaces and resources as a single unit, so they can be protected with a common snapshot. A VM can belong to only one resource group at a time. You can create a resource group for each application or workload that you want to protect, and VMs power on based on the boot order you configure within the group.

A replication plan is a set of rules about how often backups occur and how to handle failover events. It selects the source and destination sites, assigns resource groups, defines recovery mappings, and configures power-on behavior. Plans define the recovery point objective (RPO) through the frequency of data replication.

Recovery point objective (RPO) is the maximum amount of data loss that's acceptable in the event of a disaster; it's defined by the replication plan's replication frequency or schedule. Recovery time objective (RTO) is the maximum amount of time that's acceptable to recover from a disaster; it's determined by how long it takes to fail over to the DR site and restart all VMs or applications.

For steps, see Add sites in Disaster Recovery.

Discovery runs every 24 hours by default; you can customize the schedule to fit your environment. The minimum interval is 30 minutes and the maximum is 24 hours. NetApp recommends performing a few manual discoveries first to get up-to-date information, then setting the schedule to run automatically. Newly added or deleted resources are recognized at the next scheduled or manual discovery.

No. Hosting protected and unprotected VMs on the same datastore can cause problems. Namely, if the datastore is failed over, any unprotected VMs on it no longer exist at the source after failover, and Disaster Recovery won't start them at the failover site.

You should organize resources before deploying Disaster Recovery so that protected and unprotected workloads use separate subsets of datastores, and ensure a single datastore isn't protected by more than one replication plan.

If you plan to use platform-managed (ONTAP-managed) backups, use the MirrorAll policy. MirrorVault and Asynchronous are acceptable alternatives, but you must ensure the snapshot selected during failover or failback exists on both source and destination volumes, or the operation fails with a "no common snapshot found" error. MirrorLatest isn't recommended because it leaves only one common snapshot for failover. For SnapMirror relationships that Disaster Recovery manages, don't schedule updates for them outside the service, since Disaster Recovery manages replication timing.

Yes. If a SnapMirror relationship already exists between the source and destination volumes for a protected datastore, Disaster Recovery uses that relationship for all replication operations instead of creating a new one.

Yes. You can migrate VMware applications from a source site to another site using a replication plan configured for migration. After you initiate migration, the service verifies every 30 minutes that migration is progressing according to plan; you can monitor progress in Job monitoring. Migration isn't currently supported for Kubernetes-based workloads. See Migrate applications to another site.

Yes. During a test failover, Disaster Recovery creates temporary VMs from a new FlexClone volume of the selected snapshot, and maps a temporary FlexClone-backed datastore to the ESXi hosts. This doesn't consume additional physical capacity, doesn't modify the original source volume, and doesn't disrupt the SnapMirror relationship or production workloads, which continue to replicate normally. After testing, clean up the test environment using the Clean up failover test action. See Fail over applications to a remote site.

Yes. By default, all VMs boot together in parallel, but you can assign each VM a sequential number (for example, 1, 2, 3) to control boot order, or assign the same number to multiple VMs to boot them simultaneously. You can also set a boot delay (0–10 minutes) per VM to stagger startup, which is useful for ensuring priority VMs are running before later-priority VMs start.

Failback returns operations to the original source site after a disaster has been resolved. Starting from a relationship that has failed over to the target, Disaster Recovery resyncs any changes back to the original source VM or Kubernetes cluster before reversing the replication direction. The process:

See Fail back applications to the original source.

Use the Disaster Recovery Dashboard to see whether sites and plans are healthy, disconnected, or degraded; review recent warnings and failed jobs; identify protected and unprotected workloads; and view capacity at a glance. See View disaster recovery plan health.

Use Job monitoring to review job timestamps, status, and initiator (or "system" if Disaster Recovery initiated it). You can cancel a job that's "In progress" or "Queued" from its Actions menu, which is useful if a job is stuck or you need to prioritize another operation. See Monitor Disaster Recovery jobs.

You can generate reports scoped to VMware, Kubernetes, or all workloads, covering replication plan details, compliance status and job summaries. Reports can be downloaded as PDF, HTML, or JSON files. They cover a time period of one to seven days. For more information, see Create reports in Disaster Recovery.

An AppVault is the cloud storage target where Trident Protect saves Kubernetes protection data. You create an AppVault while configuring a Kubernetes replication plan.