VMware ESXi and vSphere Cluster Management

vSphere Replication Explained: VM Disaster Recovery Across Sites

Learn how vSphere Replication protects virtual machines across sites, including architecture, storage independence, RPO planning, deployment, recovery, limitations, and troubleshooting.

vSphere Replication is VMware's software-based capability for replicating virtual machine disk data from a source location to a target recovery location. It is designed for VM-level disaster recovery: if a site, host, datastore, or operational event interrupts production, administrators can recover a replica as a virtual machine at the target site.

This lesson covers the replication model, components, storage compatibility, deployment workflow, recovery operations, planning decisions, and operational cautions. It assumes familiarity with virtual machines, VMDK files, ESXi, vCenter Server, datastores, and basic disaster-recovery concepts.

What vSphere Replication Does

Replication creates and maintains a recovery copy of selected virtual machine disks. The protected VM runs at the source site, while its replicated disk data is stored at the target site. During recovery, the target copy is registered or recovered as a VM and can be powered on using the target site's compute, storage, and network resources.

Because replication operates through the virtualization layer, it is also called hypervisor-level replication. It does not require the storage arrays at the two sites to replicate directly to one another.

Replication, backup, and recovery orchestration

Data protection is the broad goal of preserving data and restoring service after loss or corruption.
Replication maintains a current or near-current copy at another location. It is useful for reducing recovery time, but it may also copy deletions, corruption, or ransomware encryption.
Backup normally creates recoverable versions retained independently over time. Backups are essential for historical recovery and protection from logical corruption.
Disaster-recovery orchestration coordinates dependencies, startup order, network changes, testing, and recovery workflows. vSphere Replication supplies replication capability; a separate orchestration product such as Site Recovery Manager may automate broader recovery plans.

How Host-Based Replication Works

At a high level, ESXi hosts participate in reading and transferring changed virtual-disk data. The replication appliance provides management and target-side services, while the target datastore receives the replica disk data.

Initial synchronization: the system transfers the data required to establish the first replica. Depending on the VM and configuration, this can be a substantial transfer.
Change tracking: after the baseline exists, the system identifies changed blocks on the protected virtual disks.
Incremental replication: changed blocks are sent to the target according to the configured replication schedule and available capacity.
Target placement: the target side writes replica data to the selected datastore and maintains the replica state.
Recovery: an administrator selects an available recovery point, maps target resources and networks, and starts the recovered VM.

The management path normally involves vCenter Server and the replication appliances. Replication data travels between participating ESXi hosts, replication services, and target infrastructure. Network reachability, firewall rules, DNS, time synchronization, bandwidth, and target storage performance all affect the result.

RPO and recovery points

Recovery point objective (RPO) is the maximum acceptable amount of data loss measured in time. A four-hour RPO means the recovery design aims to provide a recovery point no older than the permitted interval, subject to successful synchronization and platform operation.

RPO is not the same as guaranteed application consistency. A replica may represent a state comparable to an abrupt power loss. To improve consistency, use supported guest quiescing and application-aware mechanisms, and test the actual applications.

Recovery time objective (RTO) is the target time to restore service. Replication can reduce the time needed to obtain VM storage, but RTO also includes decision-making, network changes, VM startup, dependency ordering, application checks, and user validation.

Architecture and Components

vCenter Server: the management plane for vSphere inventory and replication configuration.
ESXi hosts: run the protected VMs and participate in handling changed disk data.
vSphere Replication appliance: a virtual appliance that supplies replication management and target-side services.
Source site: the location hosting production VMs.
Target site: the recovery location holding replicated data and target compute resources.
Target datastore: the datastore selected for replica disks and, where applicable, retained recovery points.
Target placement: the target resource pool, folder, host, cluster, port group, or other inventory settings used during recovery.

The appliance is deployed and registered with vCenter Server. In a cross-site design, sites are paired or otherwise configured according to the installed release. Some releases also support local replication within one vCenter environment. Interface names, supported features, appliance architecture, and configuration steps differ between vSphere generations, so use the documentation and interoperability matrix for the installed version.

Storage Independence and Compatibility

vSphere Replication operates above the storage-array layer. The source and target do not need matching storage arrays or identical storage protocols, provided the datastore types, VM configuration, and vSphere release are supported.

For example, a VM on an iSCSI-backed VMFS datastore can be replicated to an NFS datastore. A branch-office VM on local ESXi storage can be replicated to shared storage at a central site. This flexibility is valuable when sites use different vendors, protocols, or storage architectures.

Source and target storage compatibility concepts

VMFS: A clustered VMware filesystem commonly used with block storage. It may be used as either source or target when supported by the release.

NFS: A file-based datastore mounted through Network File System. It can be a target for a VM originating on VMFS or another supported datastore.

iSCSI-backed VMFS: iSCSI provides block storage over IP; the VMFS datastore abstracts that underlying protocol from the replication relationship.

Local ESXi storage: A useful source or target for some branch and lab designs, but capacity, host failure protection, and recovery compute must be assessed carefully.

vSAN and other supported datastore types: Suitability depends on the installed vSphere Replication, vCenter, ESXi, storage, and VM configuration versions.

Storage independence does not remove compatibility requirements. Validate storage policy behavior, encryption, disk format, snapshots, device mappings, datastore capacity, and performance. Target capacity must cover base replica disks, retained replica instances if enabled, VM growth, metadata, and operational headroom.

Deployment and Configuration Workflow

1. Prepare the environment

Confirm that the vSphere Replication appliance package matches the supported vCenter Server and ESXi environment.
Check product interoperability, licensing, supported VM configurations, and required privileges.
Provide DNS records, routing, firewall paths, time synchronization, and suitable target datastores.
Plan replication network segmentation and bandwidth before protecting production VMs.

2. Deploy and register the appliance

Deploy the vendor-supported OVA or OVF package.
Assign a hostname, management address or supported DHCP configuration, DNS servers, default gateway, and time synchronization settings.
Complete appliance setup and register it with the designated vCenter Server.
Verify certificates, forward and reverse DNS, clock alignment, and network connectivity.
For cross-site protection, pair or register the remote site according to the installed release.

3. Configure a protected VM

Select the VM in the vSphere management interface and start replication configuration.
Choose the target site or supported local target.
Select the target datastore and target VM placement.
Choose which virtual disks to include. Exclude disks that do not require disaster-recovery coverage only after documenting the consequence.
Set an RPO that matches business tolerance and the product's supported settings.
Configure guest quiescing and multiple point-in-time instances when supported and appropriate.
Start initial synchronization and monitor its progress.

Record the VM's recovery settings before an incident: target datastore, target compute, network mappings, disk inclusion, recovery-point policy, application startup order, DNS changes, ownership, and validation tests.

Planning Bandwidth, Storage, and Performance

Initial synchronization depends largely on the amount of data that must be copied. Ongoing replication depends more on the VM's changed-data rate than on its provisioned disk size.

A rough planning model is:

required_average_throughput ≈ changed_data_per_interval ÷ interval_duration

Add overhead for protocol behavior, retransmission, concurrent VMs, bursts, and other traffic. For example, if a line-of-business VM changes about 20 GB per day and can tolerate up to four hours of lost data, the WAN must transfer the expected changes for each interval within that four-hour window, plus operational overhead. Measure actual change rates rather than relying only on provisioned capacity.

Replication planning inputs

Protected disk capacity: determines baseline transfer and target disk requirements. Undersizing can prevent initial synchronization.

Daily change rate: indicates ongoing bandwidth and host I/O demand. High write activity can cause RPO violations.

Required RPO: determines how quickly changes must reach the target. A shorter RPO generally increases bandwidth, storage, and processing activity.

WAN bandwidth: must support concurrent initial and incremental transfers. Insufficient capacity extends synchronization time.

Latency and packet loss: reduce effective throughput and can cause delayed or failed transfers.

Target datastore capacity: must include replicas, retained instances, VM growth, and headroom.

Replica-point retention: improves recovery choices but consumes additional storage.

Host and appliance resources: must handle disk reads, replication processing, network traffic, and concurrent protected VMs.

Busy VMs, snapshots, high change rates, constrained ESXi hosts, slow target storage, and WAN congestion can all increase synchronization time. Use throttling or bandwidth controls where the installed release supports them, and schedule large initial copies to reduce production impact.

Consistency and Retention

A crash-consistent recovery state is similar to the state after an abrupt power loss. The guest filesystem may recover successfully, but applications may not have flushed all in-memory writes or completed transactions.

An application-consistent state uses guest quiescing or application-aware coordination to improve the likelihood that application data is internally consistent. The exact mechanisms and supported applications vary by guest OS, application, VMware release, and configuration. Validate the result with application owners.

Some versions and configurations support multiple point-in-time replica instances. Retaining more points can help recover from an earlier corruption or deletion, but it consumes additional target storage and may increase replication activity. Retention is not a substitute for isolated backups.

Recovery Operations

Planned recovery

For planned maintenance or a controlled site move, first confirm replication health and select a suitable recovery point. Follow the runbook to stop or quiesce the source workload, recover the VM at the target, apply network mappings, power on dependencies in order, and validate service access.

Recovery after an unplanned outage

During an outage, determine the latest usable replica point, recover the VM at the target site, and restore the required compute, storage, and network mappings. The available point may be older than the desired RPO if synchronization was delayed or interrupted.

Prevent split brain: never allow the source and recovered copies to serve the same production identity simultaneously. Confirm that the original VM is powered off or isolated, and prevent duplicate IP addresses, conflicting DNS records, and competing application instances.

Post-recovery validation

Confirm that the guest OS boots and its virtual disks are present.
Validate port groups, VLANs, IP addressing, DNS, routes, firewalls, and load balancer changes.
Start infrastructure dependencies before dependent applications.
Run application health checks and test representative user transactions.
Confirm data recency with application owners.
Document exceptions and update the recovery state.
Reprotect or reverse protection after the primary site is restored, where supported and after confirming which copy is authoritative.

Recovery Readiness Checklist

Replication health: Planned recovery requires a confirmed recent synchronization; unplanned recovery requires review of the last successful point and errors. Owner: replication administrator. Evidence: health status and timestamp.

Target capacity: Planned recovery requires a reservation check; unplanned recovery requires immediate free-space verification. Owner: storage administrator. Evidence: datastore capacity report.

DNS and network mapping: Planned recovery can validate mappings in advance; unplanned recovery uses the documented emergency network plan. Owner: network administrator. Evidence: mapping and connectivity tests.

Source shutdown or isolation: Planned recovery follows an orderly shutdown; unplanned recovery confirms source isolation before production startup. Owner: incident lead. Evidence: host, VM, and monitoring status.

Application startup order: Planned recovery validates dependencies; unplanned recovery follows the emergency runbook. Owner: application owner. Evidence: dependency and health-check results.

Functional testing: Both scenarios require guest, application, storage, and user-access validation. Owner: service owner. Evidence: signed test results.

Post-recovery reprotection: Planned recovery schedules reverse protection; unplanned recovery establishes a new protection direction after the restored site is ready. Owner: DR administrator. Evidence: updated replication configuration.

vSphere Replication Compared with Related Technologies

vSphere Replication: VM-level replication through ESXi and vSphere. It typically provides a recoverable VM at another location. It does not automatically provide complete backup history or all recovery orchestration.

Storage-array replication: Replication implemented by the storage platform. It can protect volumes or datastores efficiently, but commonly requires compatible arrays, storage features, and network designs.

Image-based backup: Creates backup images and retained versions for restore. It is better suited to historical recovery, but restore time and target infrastructure must be planned.

vSphere High Availability: Restarts VMs on surviving hosts after a host or cluster failure. It is not a cross-site replication or long-term backup system.

vSphere Fault Tolerance: Maintains a closely synchronized secondary execution instance for selected workloads. It targets rapid continuity for supported configurations, not broad site disaster recovery or backup retention.

Site Recovery Manager: A separate recovery-orchestration product that can coordinate recovery plans, dependencies, testing, and failover workflows. Its licensing and capabilities are separate from vSphere Replication.

vSphere Distributed Resource Scheduler is also separate: DRS balances or places workloads on compute resources, while replication protects VM disk data for recovery.

Licensing and Edition Availability

Edition and entitlement requirements vary by vSphere generation. Historical availability did not include the Essentials edition, but current packaging and product rights can change. Before deployment, verify current VMware by Broadcom licensing, product interoperability, supported versions, and support documentation for the exact environment.

Do not assume that licensing for vSphere Replication includes Site Recovery Manager or equivalent orchestration capabilities. Evaluate those products and features separately.

Limitations and Design Cautions

A replica is not an independent backup if it is exposed to the same administrative errors, malware, or deletion event.
Replication can copy logical corruption, ransomware encryption, and unwanted deletions. Maintain isolated, protected backups and suitable retention.
Supported VM configurations, disk types, device mappings, encryption modes, snapshots, and feature combinations depend on the installed release.
vCenter Server, ESXi, the appliance, storage, and related databases must meet supported compatibility requirements.
Replication reduces dependence on matching storage arrays, but it does not remove the need for compatible target datastores and sufficient resources.
RPO is a design objective, not proof of application consistency or a guarantee that every interval will complete.
Recovery testing must be regular and non-disruptive. Use an isolated network for test copies and remove test VMs afterward.
A usable DR program also needs ownership, communication procedures, escalation contacts, runbooks, application validation, and evidence from exercises.

Troubleshooting Common Problems

Initial synchronization is too slow

Likely causes include insufficient WAN throughput, large protected disks, latency, packet loss, high source write activity, and slow target storage. Measure bandwidth and packet quality, compare disk size and change rate with the configured RPO, inspect ESXi and appliance resource metrics, and schedule or throttle the initial copy where supported.

RPO violations repeat

Check whether changed data exceeds available replication capacity. Review health events and timestamps, measure source write activity, validate WAN and target datastore performance, and check host or appliance contention. Possible remedies include adding capacity, reducing workload change rate, adjusting the RPO when business requirements permit, or redesigning protection.

A target site or datastore cannot be selected

Check appliance registration and site pairing, permissions, target inventory visibility, datastore accessibility, and version interoperability. Incomplete registration, insufficient privileges, or an unsupported combination can hide target choices.

The recovered VM starts but its application is unavailable

Verify port groups, VLANs, IP addresses, DNS, routing, firewall rules, application dependencies, and startup order. Review guest and application logs, account for crash-consistent recovery, and confirm that the original production instance is stopped or isolated.

The target datastore fills unexpectedly

Review space used by base replica disks, retained instances, VM growth, and other protected VMs. Compare actual consumption with the capacity plan, then adjust retention, add capacity, or relocate replicas according to the recovery design.

Summary

vSphere Replication provides software-defined, VM-level disaster recovery without requiring matching storage arrays or identical storage protocols. ESXi and replication services transfer an initial copy and then changed virtual-disk blocks to a target site. Effective use depends on compatible versions, reliable networking, adequate target capacity, a realistic RPO, appropriate consistency settings, safe recovery networking, and tested operational runbooks.

Use this vSphere Replication guide as a design reference, then confirm release-specific behavior, licensing, ports, supported configurations, and procedures in the current product documentation.