VMware ESXi and vSphere Cluster Management

vSphere Replication Explained: VM Disaster Recovery Between Sites

Learn how vSphere Replication protects VM disk changes between sites, including architecture, RPO, storage independence, recovery, testing, limitations, and planning.

vSphere Replication is a software-based, hypervisor-level capability for copying virtual machine disk changes from a production location to a recovery location. It is designed to make workloads recoverable after a host, site, or infrastructure failure.

This lesson explains how replication works in an ESXi and vCenter environment, how to plan RPO and bandwidth, how unlike storage platforms can be used, and how replication differs from backup, snapshots, vSphere HA, Fault Tolerance, and DRS.

What Is vSphere Replication?

vSphere Replication is a VMware capability that replicates the disk data of selected virtual machines to another datastore or site. The source VM continues running while replication transfers an initial copy and then subsequent changes.

The primary purpose is recoverability: if the production VM or site becomes unavailable, an administrator can recover a VM copy at the target location. Replication is normally asynchronous, so the recovered VM may not contain the very latest writes made at the source.

Characteristic	Explanation
Replication layer	The ESXi hypervisor and vSphere Replication services, rather than a storage array.
Protected data	Virtual machine disk data and the configuration needed to recover the VM. Application state and external dependencies require separate planning.
Target location	A target datastore in the same site or at a remote recovery site.
Storage hardware requirement	Matching storage arrays are not required.
Storage protocol compatibility	Different datastore types and protocols can be used at the source and target, subject to product-version support.
Management interface	vCenter-integrated vSphere management interfaces.
Primary recovery use case	Recovering selected VMs after an outage or site failure.

Replication Versus Other Protection Technologies

Replication is not a synonym for backup or availability. Each technology addresses a different failure mode.

Backup: creates recoverable historical copies, often with longer retention and broader protection against deletion, corruption, or ransomware. A backup product usually includes its own catalog and restore workflow.
Snapshots: preserve a point-in-time VM disk state for short-term operational tasks. A snapshot is not a disaster-recovery plan and should not be treated as a long-term backup.
vSphere HA: restarts VMs on another host in an available cluster after a host failure. It does not create a remote recovery copy for a site outage. See enabling vSphere HA and HA admission control.
vSphere FT: provides near-continuous availability for selected workloads by maintaining a synchronized running instance. It has different workload, resource, and configuration requirements from asynchronous site replication. See enabling vSphere FT.
DRS: balances compute workloads across hosts. It can help place recovered VMs, but it is not a data-protection mechanism. See enabling DRS.

How vSphere Replication Works

Initial synchronization

When replication is first configured, an initial synchronization transfers the source VM's virtual disk contents to the target datastore. This establishes the first usable target copy. The time required depends on disk size, the amount of data that must be transferred, network throughput, and target storage performance.

Incremental replication

After the initial copy, incremental replication transfers changed virtual disk blocks. The source VM remains online, and the replication schedule determines how frequently the system attempts to create a recovery point.

Replication is performed at the hypervisor layer. ESXi observes and transfers virtual disk changes without requiring the source and target to be identical storage arrays. This is a major distinction from array-based replication, which normally depends on compatible storage systems and a storage-level replication relationship.

The source, target, and recovery workflow

The source site contains the production VM, its ESXi host or cluster, source vCenter environment, and source datastore.
The replication service transfers disk changes through the available network path.
The target site receives the changes and stores replica disks on a selected target datastore.
vCenter management tools track synchronization state, configured RPO, and reported RPO compliance.
During recovery, the administrator uses the target copy to register or recover the VM, selects compute and network placement, and powers on the workload according to the recovery plan.

Replicated disks do not automatically solve every recovery problem. Application consistency, DNS, identity services, IP addressing, firewall policy, dependencies, and startup order must be included in the recovery design.

Storage Independence and Heterogeneous Environments

Because replication occurs through ESXi rather than directly between storage arrays, the source and target sites do not need matching storage hardware. A datastore is storage presented to ESXi for VM files; common examples include VMFS, NFS, vSAN, and local storage.

For example, a production VM on a VMFS datastore backed by iSCSI can be replicated to an NFS datastore at a recovery site. A small branch office can run its source VM on shared storage while the central recovery site stores replica disks on local ESXi storage. The designs still require adequate capacity, performance, compatibility, and supported configuration.

Source datastore type	Target datastore type	Supported design concept	Example use case
VMFS	NFS	Replication between different datastore architectures.	Production block storage to lower-cost file-based recovery storage.
iSCSI-backed VMFS	Local disk	Array-backed production storage does not require a matching target array.	Branch-office workload protected at a recovery host with local capacity.
NFS	VMFS	File-based source storage can replicate to block-based target storage.	Recovery site uses a VMFS datastore for operational consistency with other workloads.
Shared production storage	Recovery-site storage	Source and target storage designs can be independently selected.	Central recovery site uses a different storage platform from production.

For related storage administration, see creating a VMFS datastore, configuring an NFS datastore, and configuring the iSCSI software initiator.

Deployment Architecture

The vSphere Replication appliance is a virtual appliance commonly distributed as an OVA package. An OVA is an appliance packaging format used to deploy a prebuilt virtual appliance. The appliance integrates replication services with vCenter Server.

A typical site-to-site design contains:

A source vCenter Server managing source ESXi hosts and protected VMs.
A vSphere Replication appliance registered with the source vCenter environment.
Source VMs whose virtual disks are being protected.
A network path between replication components, often across a WAN.
A target vCenter Server and target ESXi hosts at the recovery site, when using separate vCenter environments.
A target datastore for replica disks and target compute, folder, and network placement.

Same-site replication places the target copy in another datastore within the same general vSphere environment. It can help with datastore or storage failure, but it does not protect against a complete site loss. Site-to-site replication sends data to a separate recovery location and normally requires the source and target environments to be paired before cross-site replication can be configured.

Exact appliance roles, topology options, supported versions, network ports, and licensing eligibility depend on the vSphere Replication release. Validate these details against the release documentation and the licenses installed in the environment.

Administration Workflow

Replication is configured through vCenter-integrated vSphere management interfaces rather than by relying on version-specific command-line instructions.

Deploy the appliance: Deploy the vSphere Replication OVA and assign its IP address, DNS settings, default gateway, and time-synchronization configuration.
Register the appliance: Connect or register it with the appropriate vCenter Server instance.
Pair sites: For cross-site replication, pair the source and target vCenter environments and verify connectivity.
Select a source VM: Choose the VM and its virtual disks that require protection.
Choose placement: Select the target site or vCenter, target datastore, VM folder, resource pool or cluster, and recovery network.
Set protection parameters: Configure the required RPO and any supported point-in-time retention options.
Monitor synchronization: Watch initial synchronization, appliance health, datastore capacity, and ongoing RPO status.
Test recovery: Recover a replica into an isolated test network and document the results.
Perform recovery when required: Use the appropriate planned recovery or disaster-recovery workflow and follow the runbook.

Permissions must cover the source VM, target inventory, target datastore, compute placement, networks, and recovery operations. Review assigning permissions when designing administrative roles.

RPO and Replication Settings

Recovery Point Objective (RPO) is the maximum acceptable data loss expressed as time. An RPO of one hour means the business accepts losing up to approximately one hour of changes in the event of recovery, subject to actual replication status.

A shorter RPO generally requires replication to complete more often. That can increase WAN traffic, appliance workload, target storage activity, and the effect of a high-change-rate VM on the environment. The configured RPO is useful only when bandwidth and infrastructure can consistently sustain it.

Where supported by the selected release and configuration, point-in-time recovery allows an administrator to use an earlier retained recovery instance rather than only the newest replica. Retention consumes additional storage and should be planned explicitly.

An RPO violation means the environment is not meeting the configured recovery interval. It should be investigated rather than ignored. Repeated violations may indicate an unrealistic RPO, insufficient bandwidth, excessive VM change rate, overloaded replication components, or slow target storage.

File-server example

Suppose a file server changes frequently and the business accepts up to one hour of data loss. Configure an RPO aligned with that requirement, then verify that the WAN can transfer the changed blocks within the interval during normal and peak activity. If the measured replication lag repeatedly exceeds one hour, the design is not meeting its stated objective.

Recovery Operations

Planned recovery

Planned recovery is a controlled move of workloads when the source site is still available. Administrators can coordinate shutdown or quiescing, final synchronization, target recovery, networking, application validation, and later protection of the new primary workload.

Disaster recovery or failover

Failover switches operations from the protected source workload to its recovered target copy after an outage. The administrator validates the available recovery point, recovers the VM at the target site, selects the correct compute and datastore placement, connects the appropriate network, and powers on the workload in the required order.

Recovery should include:

Confirming that replica disks and required VM configuration are available.
Registering or recovering the VM in the target inventory.
Mapping the virtual NIC to the correct recovery port group.
Validating guest IP address, gateway, DNS, firewall, and routing behavior.
Starting infrastructure dependencies such as identity, DNS, database, and application services in the correct order.
Checking application data and service health before declaring the workload operational.

Isolated recovery testing

A recovery test should use an isolated network whenever connecting the recovered VM to production could cause duplicate IP addresses, duplicate hostnames, service conflicts, or unintended client access. Test application startup, data availability, dependencies, and the documented recovery time without disrupting production.

Failback is the process of returning workload operation and protection to the original or a new primary location. It is a separate planning exercise: determine how changed data will be synchronized back, when the workload can be moved, how network mappings will change, and how protection will be re-established.

Capabilities and Limitations

Benefits

No requirement for identical storage arrays at both sites.
Support for varied datastore types and storage protocols, when supported by the product release.
VM-level selection, allowing protection to be assigned according to workload importance.
Useful protection for many vSphere environments without making the recovery site a copy of production.
Integration with vCenter-based inventory and administration.

Dependencies and constraints

vCenter availability: Management and configuration depend on healthy vCenter environments and reachable inventory services.
Appliance health: Appliance resources, services, certificates, DNS, time synchronization, and network settings must be correct.
Connectivity: Source and target replication components need the network paths and firewall policies required by the deployed versions.
Target capacity: The recovery site needs sufficient datastore space and suitable performance for replica disks and recovered VMs.
Bandwidth and change rate: Large disks and high write rates can prevent the target from meeting its RPO.
Compatibility: vCenter, ESXi, appliance, VM hardware, datastore, and network configurations must be supported together.
Licensing: Available features and eligibility vary by vSphere Replication release and edition.

Replication alone is not a complete disaster-recovery plan. A usable plan also requires runbooks, application dependency order, DNS and identity services, network design, firewall rules, authentication, monitoring, recovery ownership, and regular testing.

Replication Planning Checklist

Planning area	Questions to answer	Example decision
RPO	How much data loss can the business accept for each workload?	Protect a file server to an RPO of one hour, then verify actual compliance.
Bandwidth	Can the link transfer the initial copy and ongoing changed blocks during peak periods?	Measure throughput, latency, packet loss, and daily change rate before selecting the RPO.
Target capacity	Is there enough space for replica disks, retained instances, and recovered VMs?	Reserve capacity for growth and point-in-time retention.
Target compute resources	Can the recovery hosts provide CPU, memory, and appropriate compatibility for protected workloads?	Prioritize critical VMs if the recovery cluster is smaller than production.
Networking	How will port groups, IP addresses, routes, DNS, gateways, and firewalls map at recovery?	Define production mappings and a separate isolated test network.
Application dependencies	Which services must start first, and which workloads require application-consistent recovery?	Start identity and database services before dependent applications.
Testing frequency	How often will recovery and failback procedures be tested?	Schedule recurring isolated tests and record recovery duration and issues.
Licensing and version compatibility	Are the installed editions and product versions eligible and supported?	Confirm the exact release matrix before deployment or upgrade.

Application consistency

Crash-consistent disk replication preserves disk changes as they reach the target, but an application may require additional coordination to produce a clean recovery state. Where available and appropriate, guest quiescing can help coordinate writes before a recovery point is created. Database-specific procedures, transaction logs, and application validation may still be necessary.

Troubleshooting Common Problems

Initial synchronization is slow or incomplete

Likely causes include insufficient WAN bandwidth, a large initial disk, a high ongoing change rate, packet loss, connectivity problems, or target datastore performance limits.

Review replication status and appliance health.
Measure bandwidth, latency, and packet loss between sites.
Confirm target datastore free space, accessibility, and performance.
Check required network paths and firewall policies.

RPO violations repeat

Compare the VM's change rate with actual network throughput. Review whether the configured RPO is realistic during peak periods, and check for overloaded appliances or target storage. Possible remedies include improving bandwidth, reducing competing traffic, changing scheduling, or selecting a less aggressive RPO that the business accepts.

The target site or datastore cannot be selected

Verify that the sites are paired, the target vCenter is available, the administrator has the required permissions, and the target datastore is mounted, accessible, and large enough. Inventory or datastore visibility problems can prevent valid placement choices.

The recovered VM powers on but the application is unreachable

Validate the virtual NIC and target port group.
Check guest IP configuration, gateway, DNS resolution, routes, and firewall rules.
Confirm that dependent services start in the required order.
Remember that an isolated test network intentionally blocks some expected production paths; include suitable test access.

The replication appliance is unavailable or unhealthy

Check the appliance power state, CPU and memory allocation, network settings, DNS, certificates, time synchronization, and connectivity to vCenter and remote replication components. Review appliance and vCenter events for service errors.

vSphere Availability and Recovery Feature Comparison

Feature	Primary purpose	Failure scenario addressed	Recovery behavior	Relationship to replication
vSphere Replication	Asynchronous VM disk replication.	Datastore, host, or site outage where a remote copy is needed.	Recover a VM at a target location using a recent recovery point.	Provides the remote recoverability layer; does not by itself orchestrate every application dependency.
vSphere HA	Restart VMs on another host.	Individual ESXi host failure within an available cluster.	VM restarts on a surviving host using accessible storage.	Can complement replication but does not replace site protection.
vSphere FT	Continuous availability for selected workloads.	Host failure for supported, appropriately sized workloads.	A synchronized running instance continues service with minimal interruption.	Addresses a different availability goal from asynchronous recovery copies.
DRS	Balance compute resources and place workloads.	Resource imbalance or placement needs.	Moves or recommends VM placement according to policy.	Can assist target resource placement but does not protect VM data.
Site recovery orchestration	Coordinate multi-VM recovery plans.	Complex site outage requiring ordered recovery.	Applies runbooks, mappings, startup order, and validation steps.	Can use replication as its underlying VM-data protection mechanism.

VMware Site Recovery Manager or comparable recovery-orchestration tooling can add coordinated plans, dependency order, network mappings, and repeatable testing. Orchestration improves execution, but it still depends on healthy replication, target capacity, networking, and application procedures.

Replication Lifecycle

Assess workload criticality, change rate, RPO, bandwidth, storage, and dependencies.
Deploy and register the vSphere Replication appliance.
Pair vCenter environments when using cross-site replication.
Configure VM, target datastore, placement, network, RPO, and retention settings.
Complete initial synchronization.
Transfer changed blocks and monitor RPO compliance.
Run isolated recovery tests and update the runbook.
Perform planned recovery or failover when required.
Validate services, users, DNS, identity, and application data.
Plan reverse replication and failback before returning operations to the original site.

Exam-Relevant Notes

vSphere Replication is hypervisor-level replication, not storage-array replication.
It transfers an initial VM disk copy and then changed disk blocks.
Source and target storage do not need to use identical arrays or protocols; examples include VMFS to NFS and iSCSI-backed VMFS to local storage.
RPO measures the maximum acceptable data loss in time, not the amount of storage capacity.
HA restarts VMs within an available cluster; FT maintains a synchronized running instance for selected workloads; DRS balances compute; replication provides asynchronous recovery copies.
Recovery testing must account for network mappings, duplicate identities or IP addresses, application dependencies, and startup order.
Always verify version support, licensing, permissions, connectivity, appliance health, and target capacity.