The replication schedule is the main DR decision, and each option narrows what else is possible. Start from the RPO, then check the hypervisor, the distance and the entity features.
| Attribute | Asynchronous | Nearsync | Synchronous |
|---|---|---|---|
| RPO | 1 hour or more | 1 to 15 minutes | 0 |
| Hypervisor | AHV or ESXi | AHV or ESXi | AHV only |
| Cross-hypervisor DR (CHDR) | Yes | Yes | No |
| Network | No stated latency limit | No minimum latency or distance | RTT under 5 ms for optimal performance |
| Recovery point type | Crash or application-consistent | Crash or application-consistent | Crash-consistent, every 6 hours |
| Retention | Linear or roll-up | Roll-up only | Not set in the schedule |
| Local schedule | Allowed | Allowed | Not allowed |
| Consistency groups | Yes | Yes | No |
| Minimum cluster | 3 nodes for 1 hour to under 6 hours | 3 nodes | 3 nodes recommended |
| External storage clusters | Yes, 1 hour or more | No | Not stated |
Do not put synchronous entities in a recovery plan with asynchronous or nearsync entities: recovery fails. Asynchronous and nearsync entities can share a plan. Figure 12.1 sets the three schedules against RPO and requirements.
Asynchronous and CHDR rules
- CHDR needs NGT on all guest VMs, flat files only, IDE, SCSI or SATA disks, and the SAN policy set to OnlineAll for non-boot SCSI disks on Windows.
- CHDR does not preserve hypervisor-specific properties (multi-writer flags, independent disks, changed block tracking, PVSCSI configurations).
- ESXi to AHV loses DNS settings on Windows VMs; reset them manually or with an in-guest script.
- vTPM-enabled VMs and encrypted ESXi VMs do not support CHDR.
Nearsync rules
Nearsync uses Lightweight Snapshots (LWS), which are metadata-level recovery points held in an LWS store on the SSD tier. The store is allocated automatically, up to 360 GB per node, and on hybrid systems 7% of the node’s SSD capacity.
- A new schedule stays hourly until seeding has replicated within the set time (an hour by default). Until then only hourly recovery points appear.
- If an entity transitions out, an alert fires, the schedule drops to hourly and the system keeps trying to return. Repeated transitions point to high LWS store usage, a change rate too high for the bandwidth, or an overloaded system.
- After an upgrade from an older AOS to 6.6 or later, transitioned-out entities never return. Remove them and protect them in a different schedule.
- Both clusters need at least three nodes, and the recovery container needs as much space as the protected VMs use.
- Deduplication on the container lowers replication speed.
- On ESXi all VM files must sit in the VMX folder, or recovery may fail with a
NoCompatibleHosterror.
Common trap: Expecting a new nearsync policy to show minute-level recovery points at once - it runs hourly until seeding completes, so seeing only hourly points early on is normal.
Common trap: Choosing nearsync for a compute cluster on external storage - such clusters do not support it, and the documented alternative is asynchronous at 1 hour or more.