By Dr. Pranay Jha, infrastructure architect and long-time vExpert, who designs and tests DR for production VCF estates.

You learn you picked the wrong replication engine during the failover, not during the design review. The datastore that held eight tier-one VMs also held thirty scratch machines, and array-based replication does not know the difference. It copies the volume. So the recovery site fills with workloads nobody meant to protect, the first sync runs far longer than the change rate predicted, and the RPO you promised slips because the link is moving five times the data it needed to.

That scene is the entire argument. Array-based and host-based replication are not two spellings of the same thing. They protect at different granularity, they handle consistency differently, and in VCF 9 one of them is not even available on the storage most people run. This part sorts out which is which, where each one wins, and the numbers that settle it.

Two places your writes can be copied

Every replication engine answers one question. When a guest writes a block, who makes the second copy and where does that copy travel? Array-based and host-based put the answer in different layers of the stack, and almost every practical difference falls out of that single choice.

Array-based: the storage copies itself

With array-based replication the storage array at the protected site copies changed blocks to a peer array at the recovery site, over the storage network, underneath the hypervisor. ESXi never sees the replication traffic. VMware Live Site Recovery, the product that used to be called Site Recovery Manager, moves no data itself here. It orchestrates. A Storage Replication Adapter, the small vendor plug-in known as an SRA, teaches Live Site Recovery how to ask your specific array to pause, reverse, or test a replicated volume. In VCF 9 the SRA and the array manager are installed on the VMware Live Recovery appliance and configured separately from vSphere Replication.

Host-based: the hypervisor copies itself

With host-based replication the copy is made inside ESXi. A filter in the host tracks changed blocks for each protected VM and ships them to the recovery site, with no dependency on the storage underneath. In VCF 9 this is Enhanced vSphere Replication, and the data path changed in a way that matters. Traffic now flows host to host, from the ESXi hosts holding the source VMs to the hosts holding the target datastore, and bypasses the replication appliance that older versions routed through. The service also spreads replicated VMs across all hosts in the target cluster and rebalances that spread roughly every thirty minutes. Enhanced vSphere Replication is now the default and only supported site to site vSphere Replication configuration for VMs.

Granularity is the difference that bites

Array-based replication protects at the level the array understands, which is a LUN, a volume, or a consistency group. Host-based replication protects one VM, and if you want, one VMDK. You cannot mix the two engines inside a single protection group. A protection group is array-based or it is vSphere Replication, never both. You can put both kinds of protection group inside one recovery plan, which is how mixed estates get a single coordinated failover.

This is the sub-topic worth slowing down on, because granularity drives cost, RPO, and the failure that shows up in your first real test. When the array replicates a volume, every VM on that volume goes along, wanted or not. If ten of the forty machines on a datastore are throwaway test boxes with a heavy change rate, you are paying to replicate their churn and stretching the RPO of the eight VMs you actually care about. Host-based replication lets you pick the eight, so the link carries only what matters.

Same eight VMs to protect. Host-based moves roughly one fifth of the steady-state bandwidth and one fifth of the initial sync, because you choose the VMs. Array-based carries the whole volume, but in return it gives you consistency across everything on it and can hit a tighter RPO. The trade is real in both directions.

RPO and consistency, where array-based still wins

Host-based Enhanced vSphere Replication reaches a 1 minute minimum RPO, but only once a VMware Live Recovery subscription is applied. On legacy SRM license keys the floor stays at 5 minutes, and Enhanced vSphere Replication also requires network encryption. Array-based RPO is whatever the array supports, which for many mid-range and high-end arrays means seconds, and for synchronous replication means zero.

The number matters less than the consistency model. Array-based replication preserves write order across an entire consistency group, so a database whose data and log volumes must move in step gets a coherent copy at the far end. Host-based replication is crash consistent per VM by default, with an optional quiesce for application consistency, and it does not coordinate write order across separate VMs. If three VMs form one application and their writes have to land in order relative to each other, host-based will not guarantee that on its own. That single property is the strongest reason array-based still exists.

Where I break with the array-first reflex

The common advice, and the array vendors will happily reinforce it, is that serious DR means array-based replication. I disagree for the typical VCF 9 estate. Most VCF runs on vSAN, and vSAN has no SRA, so array-based is not on the menu at all. You protect vSAN with vSphere Replication or with a stretched cluster. Even on classic SAN, a 1 minute host-based RPO covers the large majority of tier-one applications, and per-VM granularity saves you from carrying dead weight and from the LUN-fate trap in the callout above. I reach for array-based in two situations only: a database tier that genuinely needs write-order consistency across several VMs, and an RTO or RPO target that host-based cannot meet, meaning sub-minute or synchronous. Outside those, host-based is less to license, less to keep on the interoperability matrix, and easier to reason about when you are half awake.

Choosing and turning it on without surprising production

Here is the decision path I use before touching a single mapping.

1. If the workload lives on vSAN, stop. Use vSphere Replication or a stretched cluster. There is no array-based path.
2. If you have replicating arrays at both sites and a tier that needs write-order consistency across VMs or a sub-minute RPO, build an array-based protection group and install the SRA and array manager on the VLR appliance.
3. For everything else, use Enhanced vSphere Replication and pick VMs individually so you carry only what matters.
4. Keep the two engines in separate protection groups. Combine them at the recovery plan level when a single plan needs both.

For the host-based path, a few concrete steps decide whether the promised RPO is real. Open the outgoing host firewall port 32032 for the hbr-agent service on every host that will source or receive replication. Confirm network encryption is permitted, since Enhanced vSphere Replication requires it. Define enhanced replication mappings between the source and target datastores, then run the built-in site to site connectivity test and read the host to host latency it returns. Migrate any legacy replications to enhanced mode before you count on a 1 minute RPO, because legacy configurations are not supported past vSphere Replication 9.0.2.2.

What I would actually do

For a fresh VCF 9 design on vSAN, I do not spend a meeting on this. It is Enhanced vSphere Replication, per VM, with 1 minute RPO on the tier-one group and looser RPO on the rest. On classic SAN with arrays already replicating, I still start host-based and carve out an array-based protection group only for the database tier that needs group write-order consistency or a sub-minute floor. I do not run both engines everywhere for the sake of symmetry, because every extra SRA and array pairing is one more line to keep on the interoperability matrix and one more thing to break during an upgrade. Match the engine to the workload, license the tier you actually need, and keep the recovery plan small enough to read under pressure.

Common questions

Can I use array-based and vSphere Replication in the same recovery plan?
Yes. A recovery plan can call both an array-based protection group and a vSphere Replication protection group and fail them over together. What you cannot do is mix the two engines inside one protection group. Each group is a single type.

Does vSAN support array-based replication?
No. vSAN has no Storage Replication Adapter, so you protect vSAN workloads with vSphere Replication or with a vSAN stretched cluster. If your estate is mostly vSAN, the array versus host debate is already settled for you.

What is the real minimum RPO for each?
Host-based Enhanced vSphere Replication reaches 1 minute, but only with a VMware Live Recovery subscription. Legacy SRM license keys cap it at 5 minutes. Array-based depends on the array and can reach seconds or, with synchronous replication, zero.

Do I still need the vSphere Replication appliance now that traffic goes host to host?
Yes. Enhanced vSphere Replication moves the data path onto the hosts, but the appliance and VMware Live Recovery still handle management, pairing, and orchestration. The appliance is off the data path, not gone.

If I Storage vMotion a protected VM, does it stay protected?
With host-based replication, yes, protection follows the VM. With array-based it depends on the destination datastore. Move the VM onto a volume that is not replicated and it silently drops out of protection. Watch for that on estates that rebalance storage often.

References

Using Array-Based Replication with VMware Live Site Recovery (Broadcom TechDocs)
Protecting VMware Cloud Foundation 9, Upgrade to Enhanced vSphere Replication (VCF Blog)
Using Array-Based Replication and vSphere Replication with VMware Live Site Recovery (Broadcom TechDocs)

About The Author