Configuring VMware vSphere Replication for Disaster Recovery

Disaster recovery planning is no longer optional for Australian IT operations, and VMware vSphere Replication remains one of the most accessible tools for protecting virtual machines between sites. It works at the VM level, gives per-workload control over recovery objectives, and ties neatly into SRM if you outgrow manual recovery.

Australia's geographic spread shapes most DR designs. A primary site in Brisbane paired with Perth means crossing roughly 3,600 kilometres of fibre, while Sydney to Melbourne sits closer to 700 kilometres of cable. Combined with cyclone risks and bushfire exposure, those distances make bandwidth budgeting non-negotiable.

This walkthrough covers the configuration steps most teams miss when stitching together a DR posture. It assumes ESXi 7.x or 8.x, vCenter, and either a dedicated VRMS appliance or stretched vSAN.

Prerequisites and site pairing

Licensing and version match-ups matter before you open the vSphere client. vSphere Replication ships with the standard vSphere suite on the target site, and many Australian shops running perpetual licenses still treat replication as a checkbox feature. Confirm vCenter versions align within one minor release; asymmetry surfaces oddities in the recovery wizard. The VRMS appliance should run on a supported ESXi build and live on a management network reachable from both sites.

Topology choices flow from geography. Common Australian pairings include Sydney to Canberra for government, Melbourne to Hobart for finance, and Perth to Adelaide for resources-sector deployments. If you run a compact lab alongside production, the Virtxpert home lab guide can stand in as a tertiary target.

vSphere Replication is content-agnostic. It writes VMDKs of the same provisioned size to the recovery datastore, doubling your sizing choices on the target side. Avoid mixing thick-provisioned sources with thin-provisioned targets when the recovery datastore sits on slower spinning rust, since the initial sync dominates the transfer window.

Network and bandwidth budgeting

Replication traffic rides over an HTTPS channel on port 31031, and the VRMS on the target initiates the outbound connection back to the source vCenter. That reverse-initiation eases life with the asymmetric NAT patterns common in regional Australian branches. A firewall rule allowing 31031 from target VRMS to source vCenter is the minimum; running Site Recovery Manager also requires ports 8093 and 8094.

Bandwidth math is where most misconfigurations happen. Multiply daily change rate by protected VM count, divide by available WAN throughput, and decide what RPO is realistic. A 100 Mbps link between Brisbane and Sydney supports a five-minute RPO for twenty to thirty mid-sized VMs, but burst-heavy workloads skew that quickly. Compression is on by default and helps roughly two-fold for typical Windows and Linux guests.

For smaller offices riding the NBN, treat replication as a scheduled job rather than a continuous stream. Tag non-critical VMs to replicate overnight, reserving working-hours bandwidth for user traffic. The engine supports multiple schedules per VM, keeping this granularity simple.

Deploying the VRMS appliance

The appliance arrives as an OVA and deploys like any other vSphere template. Give it at least 8 GB of RAM and four vCPUs, more if you scale past a hundred protected VMs. The wizard prompts for IP, DNS, and NTP, and the appliance joins a domain only if you have configured single sign-on extensions. For most Australian deployments, leaving it in enhanced linked mode with the recovery vCenter is the simplest path.

After deployment, register the appliance with the target vCenter. Under the recovery site's home, choose Site Recovery, then Open Site Recovery, and point the integration plug-in at the VRMS. This step pairs both halves of the replication fabric; without it, the plug-in will not show protected workloads.

A common gotcha is certificate trust. Self-signed certs work for proof-of-concept, but regulated Australian industries such as healthcare should swap in internal CA-signed certificates before the first real cycle. Mismatched certificates silently degrade replication, and the failure mode is rarely obvious until you check the appliance logs.

Creating protection groups

Protection groups bundle virtual machines that share recovery characteristics. Group by RPO first, application stack second; mixing a five-minute-RPO database with a 24-hour-RPO file server forces the slower cadence on everything. The settings tab sets the RPO interval, retained recovery points, and whether quiescing uses VMware Tools snapshots or application-consistent VSS.

Retention deserves more attention than it usually gets. The default of 24 recovery points per VM uses about as much storage on the recovery side as one extra full clone, surprising teams accustomed to backup tools. If the recovery datastore is tight, reduce the per-VM count and lean on file-level backups for older state.

Recovery plans and failover orchestration

A recovery plan is the order book for what happens during a real outage. Orderly shutdown of dependent VMs, startup of the database tier, and IP remapping for guests whose addresses change between sites can all be encoded into a plan. For teams still getting comfortable with the toolset, the troubleshooting and tuning guide covers how DR interacts with HA admission control and DRS affinities during failover, useful context when combining replication with cluster-level resilience.

Test failovers should run against an isolated network so you do not accidentally cut over production. Most Australian teams gate test runs inside change windows and notify operations via their standard paging channels. The notification step matters: it keeps muscle memory accurate.

Validating the design

Configuration is only the start. Schedule at least one planned migration exercise per quarter where you actually move a workload back and forth, measure time to first byte of services, and confirm DNS, firewall rules, and application authentication survive the cutover. Documentation drifts quickly, and the only way to catch stale runbooks is to use them against live systems while you have room to roll back.

When the design holds up, replication becomes a quiet background service rather than a heroic manual effort, which is what a sustainable DR posture looks like for an IT team juggling other priorities. Capture lessons from each drill and feed them back into recovery plans so the next iteration runs smoother.

If you are weighing replication against backup-only strategies or thinking about layering it with cloud-target extensions, reach out through the Virtxpert contact page for a short consultation and to grab the free PowerCLI toolkit that pairs with these workflows.