DR Design for a 30-Minute RPO
A software company runs 180 VMs at its primary site and needs a DR capability for a new compliance requirement. The current protection is a nightly backup to a tape library, with a 24-hour RPO and no tested restore. The DR site is 400 km away and has a 200 Mbps IP link; the production data is 12 TB with a measured daily change rate of 6%. The business requires an RPO of 30 minutes and an RTO of 4 hours for the top 60 VMs; the remaining 120 VMs can tolerate 24 hours. The DR site has a three-node Nutanix cluster with enough CPU and memory but only 8 TB of usable storage. The network team says latency between sites is 8 ms RTT and jitter is low. The compliance team wants quarterly DR tests with evidence.
1. Select a replication method for the top 60 VMs and justify it against the 30-minute RPO and 4-hour RTO.
Read the worked answer
Use asynchronous replication as the baseline, with NearSync only if validated:
- Change rate: 12 TB × 6% = 720 GB/day, about 30 GB/hour or 67 Mbps average. A 200 Mbps link can carry that, but peak change rates and snapshot transfer time determine whether a 15-minute schedule can actually finish inside 15 minutes.
- Async every 15 minutes for the top 60 VMs gives margin against the 30-minute RPO; retain enough snapshots for operational recovery and compliance. If each delta is small, replication completes well within the interval.
- NearSync can meet a tighter RPO, but it imposes latency and bandwidth requirements. An 8 ms RTT may be outside supported limits depending on AOS version, so validate before promising it.
- RTO: 4 hours is mostly boot order, DNS/AD, and application validation, not replication. Document and test the runbook.
Do not put all 180 VMs on the same schedule; protect the 120 lower-tier VMs with nightly backups or daily replication.
2. Does the DR site have enough usable storage? Show the calculation and identify the risk.
Read the worked answer
Assume the top 60 VMs are about 70% of production data, or 8.4 TB. The DR cluster has 8 TB usable. That is already below the protected set before snapshots, metadata, and operational headroom; 8.4 TB cannot fit. Even if the protected set were smaller, retaining multiple snapshots on the DR cluster consumes additional space.
Options:
- Reduce the protected set to the truly critical VMs and restore the rest from backup.
- Add capacity to the DR cluster or use a larger node model.
- Exclude temp/swap/pagefile data and validate the actual consumed space.
- Keep longer retention on the primary or a secondary target, not the DR cluster.
The risk is a DR design that passes a paper RPO but cannot complete a failover because the target datastore is full. The calculation must use usable capacity after RF2 and reserve, not raw disk.
3. Design the quarterly DR test so it provides evidence without disrupting production.
Read the worked answer
Design the test around cloned snapshots, not a production failover:
- Replicate as normal, then clone the latest DR snapshots into an isolated test network/VLAN at the DR site.
- Power on the clones in the correct boot order; include AD/DNS and the application dependency chain.
- Start a timer at the declared disaster and stop when the business transaction test passes; record actual RTO and any manual steps.
- Validate data consistency against the source (row counts, checksums, or application reports) and record the achieved RPO.
- Capture screenshots/logs, update the runbook, then delete the clones and clean up replication state.
Run this quarterly and after major changes. The evidence should show the gap between the designed RTO and the measured RTO, plus corrective actions.