By Dr. Pranay Jha, infrastructure architect and long-time vExpert, who designs and tests DR for production VCF estates.
The replication status is green. The RPO chart shows five minutes. Then a host dies, you fail over the payments VM, and it boots twenty-two minutes stale. The dashboard was not lying to you. It was telling you the last time a replication cycle finished, and that cycle had been quietly slipping for an hour because the change rate outran the pipe. Nobody watches the sync duration until the sync duration is the whole story.
vSphere Replication is the mover under most VCF 9 recovery plans, and it is the part people understand the least. It copies data at the host level, ignores what array sits underneath, and lets you set a per-virtual-machine recovery point. That flexibility is also the trap. This part is for the admin who has to make the recovery point real, not the datasheet number. It covers how the data actually travels in VCF 9, why the RPO you configure is not always the RPO you get, and how to size the link so the promise holds at 3 a.m.
Bottom line: vSphere Replication is asynchronous, host-based, and storage-agnostic. In VCF 9 the data path moved off the appliance and onto the ESXi hosts, and RPO can go as low as one minute. None of that changes the physics: your recovery point is only as good as the changed data you can ship inside the window.
How host-based replication moves your data
Array-based replication happens below the hypervisor, inside the storage controller. vSphere Replication works the other way around. It sits in the ESXi I/O path, watches the writes going to a protected VM, and ships only the changed blocks to the target site. Because it lives above the storage layer, it does not care whether the source is vSAN and the target is an NFS array, or whether the two sites run different hardware entirely. That storage independence is the single best reason to reach for it.
The changed-block path
Each protected VM gets a lightweight filter in the host I/O stack that tracks which blocks change. On every replication cycle the host reads those dirty blocks, optionally compresses them, and sends them to the target, where they are applied to a shadow copy of the disk. The first cycle is different and painful: it is a full synchronization that copies every allocated block, not just the deltas. On a one terabyte VM that initial copy can run for hours and saturate the link while it does. After that, steady state is only the churn.
What Enhanced replication changed in VCF 9
In older releases every replicated block flowed through a vSphere Replication appliance, which became the bottleneck at scale. VCF 9 standardizes on Enhanced vSphere Replication, where the traffic goes host to host and the appliance drops back to a control-plane role. The target side load balances replications across every host in the destination cluster and rebalances automatically about every thirty minutes, so one host does not carry the whole inbound load. Enhanced replication also requires network encryption, and it opens a new outbound firewall requirement on TCP port 32032 for the hbr-agent service. Enhanced mode is now the only supported site-to-site configuration going forward, so if you are coming from a legacy setup this is not optional homework.
The RPO you set is not always the RPO you get
You can set a recovery point objective per VM anywhere from five minutes to twenty-four hours on standard licensing, and Enhanced replication with a VMware Live Recovery subscription drops the floor to one minute. Here is the part the number hides. The RPO is measured from the last cycle that finished, not the one that is running. If a cycle takes longer than the interval, because a nightly batch job just rewrote half the disk, the effective recovery point stretches past the target until the backlog clears. vSphere Replication will warn you, but the data has already aged.
Multiple points in time recovery softens one class of disaster. With it configured, vSphere Replication keeps up to twenty-four historical recovery points, which appear as snapshots on the recovered VM. If corruption or ransomware replicated along with your good data, you can roll back to a point before the damage instead of recovering the poisoned latest copy. Keep the count to the lowest number that meets the requirement, because every retained point costs space and management overhead at the target.
From the field
The upgrade to Enhanced replication that looks cleanest on paper is the one that bites. A team migrated their replications, watched the config apply without error, and only found out at the next test that half the VMs had a stalled initial sync. The cause was the new outbound rule on TCP 32032 for hbr-agent. It was open on the source hosts and closed on two target hosts, so those hosts silently could not receive the host-to-host stream. The UI showed the mapping as valid because the appliance path still answered. Run the site-to-site connectivity test from the Enhanced Replication Mappings view on every host pair, not just one, before you trust it.
Bandwidth is where good RPO promises go to die
Every replication cycle has to move the blocks that changed since the last one. Shorter RPO means less time for repeated writes to the same block to collapse into one transfer, so a one-minute RPO ships noticeably more data over a day than a four-hour RPO on the exact same workload. The interval you pick is a bandwidth decision disguised as a recovery decision.
Take one VM with about eighty gigabytes of changed data per day at a coarse measurement. As the RPO tightens, the effective daily transfer climbs because fewer overwrites coalesce. The table below turns that into sustained bandwidth, first per VM, then for a fifty-VM protection group. These are averages. Replication is bursty, so plan the link for peaks of roughly two to three times the average, not the average itself.
| RPO | Effective data per day (1 VM) | Sustained avg, 1 VM | Sustained avg, 50 VMs |
|---|---|---|---|
| 4 hours | 80 GB | 7.4 Mbps | 370 Mbps |
| 1 hour | 95 GB | 8.8 Mbps | 440 Mbps |
| 15 minutes | 120 GB | 11.1 Mbps | 555 Mbps |
| 5 minutes | 150 GB | 13.9 Mbps | 695 Mbps |
| 1 minute | 200 GB | 18.5 Mbps | 925 Mbps |
Worked example
Fifty VMs at a fifteen-minute RPO average about 555 Mbps of replication. Peaks of two to three times that reach 1.1 to 1.7 Gbps. A single gigabit DR link will run hot and start missing cycles during busy hours, which is exactly when you least want the recovery point to slip. Either give the link real headroom, closer to a ten gigabit path, or accept a longer RPO on the noisy VMs. Do not set the interval you wish you had and hope the pipe keeps up.
Where I disagree with the one-minute reflex
Enhanced replication can hit a one-minute RPO, so people set a one-minute RPO. I think that is usually the wrong default. Async host-based replication can never give you zero data loss no matter how small the interval, because there is always a cycle in flight. If a workload truly cannot lose a single transaction, vSphere Replication is the wrong tool and you want synchronous array replication instead, which is where the next part goes. For everything else, a one-minute recovery point buys you four minutes of freshness over a five-minute setting while multiplying bandwidth and host CPU for compression and encryption.
My default for tier-one VMs is fifteen minutes, dropped to five for the handful of databases where the business genuinely feels the difference, and one minute reserved for the rare case that can justify the pipe. Tier-two and tier-three workloads sit at one to four hours and free up bandwidth for the systems that matter. Set the RPO to the business impact of lost data, not to the smallest number the license allows.
What I would actually do
Tier your VMs by data-loss impact and assign three RPO bands, not one blanket number. Fifteen minutes for tier one, one to four hours for the rest, five or one minute only where a named business owner asks for it and the link can carry it. Seed the initial sync for anything over a few hundred gigabytes so the first copy does not starve every other replication. Then measure actual sync duration for a week and fix the VMs whose cycles run long before you call the design done.
Turning it on without breaking production
The enabling steps are simple. The order and the guardrails are what keep a migration from turning into an outage.
- Open the outbound firewall rule on TCP 32032 for hbr-agent on every host at both sites, then confirm it under Host, Configure, Firewall, Outgoing.
- Define the Enhanced Replication Mappings between source and target datastores and run the built-in site-to-site connectivity test on each host pair.
- Seed large VMs where you can, so the initial full sync copies as few blocks as possible.
- Migrate replications to Enhanced mode in small batches, watching sync duration, not just the green status.
- Set MPIT retention to the lowest count that meets your rollback requirement.
Before you change production
Migrating replications to Enhanced mode and running a recovery both touch live workloads. Reconfiguring a replication can trigger a fresh full sync that saturates the link, and a real recovery powers on VMs at the target. Do the migration in a maintenance window, in batches, and never run a live failover as your first validation. Test in an isolated network first, which is the topic of Part 8.
What to validate before you rely on this
- The outbound TCP 32032 rule is open on every host at both sites, verified by the connectivity test on each host pair, not one sample.
- Measured sync duration stays comfortably inside the RPO during your busiest hours, not just at idle.
- The DR link has headroom for peak replication plus the initial full sync of any newly protected VM.
- MPIT retention actually covers a rollback window long enough to survive silent corruption or ransomware.
- Every protected VM has completed its first full sync before you count it as protected.
Myth versus reality
| What people assume | What actually happens |
|---|---|
| A one-minute RPO means at most one minute of data loss. | It means the target is one minute behind only when cycles finish on time. Under load the effective recovery point stretches until the backlog clears. |
| vSphere Replication needs matching storage at both sites. | No. It is host-based and storage-agnostic. Source and target can run entirely different arrays. |
| Turning on replication is instant protection. | The first cycle is a full sync that can run for hours and saturate the link. A VM is not protected until that completes. |
| The appliance still moves all the data in VCF 9. | Enhanced replication moves data host to host over TCP 32032. The appliance is control plane only. |
| MPIT protects me from ransomware automatically. | Only if retention spans far enough back to predate the infection, and only if you actually roll back to a clean point instead of the latest copy. |
Crash consistent is the default, and it is not always enough
By default vSphere Replication gives you a crash-consistent copy. The recovered VM looks exactly as it would after a hard power loss: the filesystem is intact and most modern applications replay their logs and come up clean. For a database mid-transaction, crash consistent can still mean a recovery that needs manual repair. When you need the application to be quiesced at the moment of capture, enable guest OS quiescing so VMware Tools flushes pending writes, using Microsoft VSS on Windows guests, before the point is taken.
Quiescing is not free. It briefly stuns the guest and leans on the application to cooperate, and on a busy database that pause can be noticeable. Compression and the mandatory encryption in Enhanced replication also spend CPU on both the source host and the host managing the target datastore. None of these are reasons to avoid the features. They are reasons to turn them on deliberately, per VM, and to watch host CPU on the busiest source hosts after you do.
vSphere Replication is the workhorse that makes most VCF 9 recovery plans possible, and it rewards the admin who treats the recovery point as a bandwidth budget rather than a checkbox. Get the pipe and the sync durations right, and the green status finally means what you thought it meant. Start with Part 2 if you have not fixed your RPO and RTO targets yet, then come back and size the link to match. If you build DR the way it reads on the datasheet, you will meet the datasheet and miss the recovery.
« Previous: Part 3 | VMware Live Recovery Complete Guide | Next: Part 5 »
References
- Protecting VMware Cloud Foundation 9: Upgrade to Enhanced vSphere Replication (VCF Blog)
- How the Recovery Point Objective Affects Replication Scheduling (Broadcom TechDocs)
- Best Practices for Using and Configuring vSphere Replication (Broadcom TechDocs)
About The Author
DrJha