Backup, Snapshots, and Replication on AOS 7.3.

Snapshots, replication, and backup get treated as one feature on Nutanix because they share the same storage primitive. They are three different jobs with three different recovery contracts, and confusing them is how clusters end up with a retention policy that is not a backup and a replication schedule that is not disaster recovery. This article separates the constructs, maps the three replication tiers to the RPO they actually deliver, and covers what AOS 7.3 and Prism Central 7.3 changed.

The snapshot primitive

Every data protection feature on the platform sits on one mechanism: the Distributed Storage Fabric snapshot. It uses a redirect on write approach. When a vDisk is snapshotted, the existing blocks are marked immutable and new writes are directed to a fresh vDisk. Reads resolve to the correct blocks through a metadata lookup. There is no copy at snapshot time, so the operation is near instant and the cost is metadata, not duplicated data.

Snapshots are taken by Cerebro, the cluster service that owns data protection orchestration, and executed by Stargate at the storage layer. Because the snapshot is metadata driven, the work of creating one does not scale with the size of the vDisk. That is the property the rest of this article depends on.

Crash consistent versus application consistent

A default snapshot is crash consistent. It captures the on disk state at a point in time, which recovers the same way a VM recovers from a power loss. For most workloads that is acceptable. For databases and transactional applications it is not, because in flight writes and application buffers are not flushed.

Application consistent snapshots require Nutanix Guest Tools (NGT) inside the guest. On Windows, NGT integrates with the Microsoft VSS framework through a native Nutanix VSS provider to quiesce the application before the snapshot. On Linux, NGT runs pre_freeze and post_thaw scripts instead, because there is no VSS equivalent. One detail that bites people: the application consistent label is only useful if the guest integration actually quiesces the workload. If freeze or thaw scripts are missing, empty, broken, or return errors, the result can fall back to crash consistent behavior. Install NGT and validate the scripts before you trust the label.

Design note NGT is not only about consistency. It also handles in guest IP reconfiguration during failover and is strongly recommended on every protected VM so you are not installing it across a fleet during an incident. Treat NGT as a standing requirement for any VM that participates in DR, not a per workload decision.

Two frameworks: Protection Domains and Protection Policies

There are two ways to configure protection on Nutanix, and which one you use determines where you administer it and what it can do.

Protection Domains are the original construct, configured in Prism Element under Data Protection. A Protection Domain is a group of VMs and volume groups snapshotted and replicated together on a schedule. Inside a Protection Domain, a consistency group is the set of entities snapshotted at the same instant so they recover in a consistent state with each other. Protection Domains are per cluster and managed locally.

Protection Policies and Recovery Plans are the Prism Central framework, previously marketed as Leap and now called Nutanix Disaster Recovery. A Protection Policy defines what is protected, at what RPO, and where recovery points replicate. A Recovery Plan orchestrates the actual failover: boot order, network mapping, and inter stage scripts. This is the framework Nutanix is investing in, and it is the one to use for anything beyond single cluster local snapshots.

Nutanix data protection object model from snapshot through recovery plan

The data protection object model. A recovery point is one snapshot in time; everything above it is policy and orchestration.

Gotcha Do not mix the two frameworks on the same entities. A VM protected by both a Prism Element Protection Domain and a Prism Central Protection Policy produces duplicate snapshots, conflicting retention, and capacity you cannot account for. Pick one framework per workload and standardize on Protection Policies for new designs.

The three replication tiers

Replication copies recovery points to a remote target. The platform offers three tiers, and the difference between them is the RPO they deliver and the mechanism underneath. Choosing a tier is a per workload decision driven by how much data loss the application tolerates, not a cluster wide setting.

Nutanix replication tiers mapped to RPO from zero to one hour and beyond

The three replication tiers across the RPO spectrum. Latency budget and change rate, not preference, decide where a workload lands.

Tier	RPO	Mechanism	Constraint
Asynchronous	1 hour or greater	vDisk based snapshots in the Extent Store, replicated on schedule	Replicates changed data only; the workhorse tier for most workloads
NearSync	1 to 15 minutes	Lightweight snapshots (LWS), OpLog based markers held on the SSD tier	Sensitive to bandwidth, change rate, and scale limits; validate the current entity maximums for the protection framework you use
Synchronous (Metro)	Zero, at VM granularity	Every write committed to both sites before acknowledgement	Sites must be under 5 ms round trip latency

Asynchronous is the default choice and the only tier that allows long RPO windows. NearSync uses a separate snapshot technology: rather than vDisk snapshots, it writes OpLog based markers called lightweight snapshots, which are constant time to create and replicate continuously. To hold the RTO sane, NearSync also creates an hourly intermediate snapshot retained for six hours and a daily snapshot retained for five days, so a failover has checkpoints to fall back to.

Synchronous replication gives zero RPO because the write is not acknowledged to the guest until both sites have it. That guarantee is why the 5 ms latency ceiling exists. Sync also keeps a second copy of VM data, VM metadata, and the applied policies on the partner cluster, which is what makes live migration between the two sites possible. The multi site mechanics of Metro, including the witness, belong to NCD-12 and are covered there.

Design note Replication only ever moves changed data after the first pass, but the first pass moves a full copy. Size initial seeding and ongoing bandwidth against your real change rate, and remember that aggressive RPOs amplify the cost of every bandwidth shortfall. A 1 minute NearSync target with a saturated link does not fail loudly; it falls behind quietly.

Remote sites, availability zones, and topologies

In the Protection Domain world the replication target is a remote site: another Nutanix cluster with enough compute and storage to absorb a full site failure. In the Prism Central world the unit is the availability zone, and you pair availability zones so they synchronize the policies, recovery plans, and categories used for DR. The rule that saves you grief: always create protection policies, recovery plans, and categories on the primary cluster, and let pairing replicate them.

Supported topologies cover one to one, one to many, and many to one. One to many fans a workload out to multiple recovery targets; many to one consolidates many primary clusters onto a single recovery cluster, which is the common service provider shape. For cloud and third site targets, Multicloud Snapshot Technology (MST) replicates snapshots to object storage rather than a standby cluster, which removes the standby compute cost for Pilot Light and Zero Compute recovery.

Recovery Plans and orchestrated failover

A replication schedule that lands recovery points at the far site is not disaster recovery. Recovery is what happens when you run the plan. A Recovery Plan defines the boot sequence, maps source networks to recovery networks, and runs scripts between stages so applications come up in the right order with the right addresses.

Recovery Plans support planned and unplanned failover. Planned failover is a clean migration with no data loss when the primary is still reachable. Unplanned failover recovers from the last replicated recovery point after a primary loss, so the data exposure equals the RPO of the tier you chose. Test the plan with the built in validation and test failover features before you need it, because network mapping errors and missing scripts surface in the test, not in the design review.

Retention is set per schedule and comes in two forms. Linear retention keeps the most recent n recovery points at a site. Roll-up retention collapses older recovery points into coarser intervals as they age, up to the configured retention period, which keeps long retention from consuming a recovery point for every interval. Use Roll-up for long horizons and Linear for short, dense windows.

Gotcha If the cluster hosting your Prism Central VM is also the primary you are failing over from, a primary site loss can take Prism Central with it, and Prism Central is what runs the Recovery Plan. Plan where Prism Central lives so the control plane survives the failure it is meant to recover from.

Third party backup integration

Native snapshots and replication are recovery points inside the platform. They are not, on their own, an independent backup. For an air gapped or off platform copy, integrate a backup product. Nutanix exposes data protection APIs that backup vendors call to create and read snapshots, and the v4 Disaster Recovery APIs provide Changed Regions Tracking and Changed Blocks Tracking so vendors can compute incrementals without rereading whole disks. Supported partners include Veeam, HYCU, Commvault, Cohesity, and Rubrik.

A snapshot created through this API is a third party snapshot. The platform does not manage its lifecycle; it holds the snapshot until the backup product issues a delete. That is by design, and it is also the source of the most common alert in this area. The NCC check aged_third_party_backup_snapshot_check fires when one of these snapshots outlives its threshold, default 7 days and configurable from 1 to 365. An alert here usually means the backup product failed to clean up, not that the cluster is broken, but stale third party snapshots do consume capacity, so investigate rather than just raising the threshold.

For a turnkey appliance, Nutanix Mine packages a backup product, Veeam or HYCU, onto Nutanix hardware so the backup target lives on the same platform. Given Veeam v13 handles AHV agentlessly at the hypervisor level, through its AHV plug-in and per job workers, and keeps a single rolling backup snapshot per VM for CBT computation, expect to see one third party recovery point per protected VM in Prism Central as normal steady state, not a leak

What AOS 7.3 and Prism Central 7.3 change

This series targets AOS 7.3 with AHV 10.3 and Prism Central 7.3, released 24 June 2025, with AOS 7.3 supported through June 2027. The data protection changes in this release matter for design.

Replication encryption by default. Replication traffic is now encrypted in transit by default, which removes a manual step from any cross site design.
No firewall ports for sync setup. Synchronous replication setup and cross cluster live migration no longer require opening dedicated firewall ports, which simplifies the network discovery on Metro designs.
vTPM VMs in PD based async DR. Asynchronous replication now supports vTPM enabled VMs in Protection Domain based DR, provided both primary and recovery sites run AOS 7.3 or later. Previously these VMs needed workarounds.
Higher replication capacity ceilings. All flash nodes now support larger per node capacity for replication at the shorter RPO tiers, 185 TB for the 1 hour to under 6 hour async range and 370 TB for 24 hour and longer RPO. Verify the exact figure for your node model on the portal before sizing.
MST third site combinations. Multicloud Snapshot Technology now supports Azure Blob in addition to S3 compatible targets, and MST policies can combine with other replication types to serve a third site, for example synchronous to a secondary cluster and MST to the cloud.
Prism Central Backup and Restore (PCBR). Prism Central 7.3 can back up the Prism Central instance itself to S3 compatible object storage, which protects the control plane that runs your Recovery Plans.

Verify before designing The 185 TB and 24 hour capacity figures are release and platform sensitive. Confirm the exact per node replication capacity limits for your specific node platform against the current Data Protection and Recovery guide on portal.nutanix.com before committing them to a design.

A build order for a new protection design

Classify workloads by RPO and RTO. Sort every VM into a tier before touching the UI. Most land in async; reserve NearSync and sync for the workloads that justify the cost and the latency budget.

Install and validate NGT on every VM that needs application consistency or will participate in failover, and confirm the freeze and thaw scripts on non Windows or client OS guests actually quiesce I/O.

Standardize on Protection Policies in Prism Central for new designs. Reserve Protection Domains for existing Prism Element configurations you are not yet migrating, and never protect the same VM in both.

Pair availability zones and author on the primary. Create policies, recovery plans, and categories on the primary so pairing replicates them. Place Prism Central where it survives a primary site loss.

Set retention deliberately. Linear for short dense windows, Roll-up for long horizons. Size the recovery point count against capacity, not habit.

Add an independent backup. Integrate a supported backup product through the data protection API for an off platform copy, and monitor the aged third party snapshot check so cleanup failures surface early.

Run a test failover. Validate the Recovery Plan and execute a test failover before the design is signed off. Network mappings and boot order fail in the test, not the diagram.

Common design mistakes

Treating replication as backup. A replicated recovery point on a second cluster is still inside the platform and still subject to a logical fault or ransomware that propagates with it. Keep an independent copy.
Trusting an unvalidated application consistent label. Empty or broken freeze scripts produce a crash consistent snapshot wearing an application consistent label. Validate, do not assume.
Setting an RPO the link cannot sustain. A NearSync target on an undersized link falls behind silently. Size bandwidth to the change rate, then pick the RPO.
Double protecting VMs across both frameworks. Protection Domain plus Protection Policy on the same VM means duplicate snapshots and capacity you cannot reconcile.
Putting Prism Central in the blast radius. The control plane that runs failover cannot live only on the site it is meant to recover.
Never testing the Recovery Plan. A plan that has not been test failed over is a hypothesis, not a recovery capability.

Key Takeaways

Every data protection feature sits on the DSF redirect on write snapshot, taken by Cerebro and executed by Stargate, metadata driven and near instant.
Crash consistent is the default; application consistency requires NGT, and on Linux and Windows client editions the consistency label is only as good as the freeze and thaw scripts.
Two frameworks exist: Prism Element Protection Domains and consistency groups, and Prism Central Protection Policies and Recovery Plans (Nutanix Disaster Recovery). Standardize on the latter and never mix them on one VM.
Three replication tiers: Async at 1 hour or greater on vDisk snapshots, NearSync at 1 to 15 minutes on lightweight OpLog snapshots with framework specific scale limits, and Synchronous at zero RPO with a sub 5 ms site latency requirement.
Recovery Plans, not replication schedules, are disaster recovery. They orchestrate boot order, network mapping, and scripts, and must be test failed over before sign off.
Native snapshots are not an independent backup. Integrate a supported backup product through the v4 Disaster Recovery APIs and watch the aged third party snapshot check.
AOS 7.3 and Prism Central 7.3 add default replication encryption, portless sync setup, vTPM async PD replication, higher replication capacity ceilings, MST to Azure and third site combinations, and Prism Central self backup to object storage.