Protection Domain RPO Missed After WAN Change
A three-node cluster at the primary site protects 60 production VMs with a protection domain named PD-PROD. The schedule takes a snapshot every 4 hours and replicates to a remote Nutanix cluster. Local retention is 7 days; remote retention is 14 days. The WAN link is 200 Mbps, and the daily change rate is 1.2 TB. For the last three days, replication tasks have taken longer than 4 hours, and the remote site is 9 hours behind. Prism shows the source cluster at 68% used and the remote at 41% used. The customer wants a 1-hour RPO without buying more WAN bandwidth and asks whether changing the schedule from 4 hours to 1 hour will solve it.
1. Calculate whether the WAN can support a 1-hour RPO at the current change rate.
Read the worked answer
A 1.2 TB daily change rate averages about 50 GB per hour. A 200 Mbps link has a theoretical throughput of about 90 GB per hour, or roughly 54–63 GB per hour at realistic 60–70% efficiency. On paper, the average change fits a 1-hour RPO, but the current 4-hour tasks are already taking longer than 4 hours, which means actual replication throughput is below the expected rate or the change rate is bursty. Simply changing the schedule to 1 hour would create more snapshots and overlapping replication work before the bottleneck is fixed. Measure WAN utilization during replication, latency and packet loss, snapshot size, and remote cluster health. Only after sustained throughput exceeds about 50 GB per hour with margin should a 1-hour RPO be considered.
2. What sequencing would you use to meet a 1-hour RPO without adding bandwidth?
Read the worked answer
First fix the existing replication path: confirm the WAN is actually being saturated, check for packet loss and latency, verify QoS or rate limits, and review PD-PROD logs for slow snapshot or transfer phases. Confirm the remote cluster has no active rebuild or capacity issue. Keep the 4-hour schedule while testing a single smaller protection domain at 1 hour to establish real throughput. If the test meets the window with margin, move PD-PROD to 1 hour and stagger snapshot times so replication does not collide with backup or other replication jobs. Consider NearSync only if the requirement tightens below an hour and the link latency supports it. Changing the schedule without fixing throughput will only increase backlog and snapshot count.
3. What capacity and retention impacts should be checked before shortening the schedule?
Read the worked answer
Local retention of 7 days at 4 hours produces 42 snapshots per VM; at 1 hour it produces 168, or about 10,080 snapshots across 60 VMs. Remote retention of 14 days at 1 hour produces 336 per VM, or about 20,160 across the protection domain. Nutanix snapshots are incremental, but metadata and changed-block tracking still consume space and increase replication bookkeeping. Check source and remote container capacity, current snapshot usage, and NCC alerts before changing the schedule. The remote at 41% may look comfortable, but 14 days of hourly snapshots can grow quickly. If capacity is tight, reduce retention, split the protection domain, or keep a longer RPO for lower-tier VMs rather than applying 1-hour snapshots to all 60 VMs.