Replication and Disaster Recovery

Architecture Overview

Site Pairing and Intersite Coordination

Before replication can be enabled, two VMease sites must be paired.

Pairing creates a trusted link between the local and remote DR sites. The sites share metadata, tunnel details, host information, and coordination settings. Depending on your setup, sites can connect using routing or a VPN.

After pairing, the sites keep track of their connection and coordination status. This helps VMease know if the remote site is available and allowed for multisite operations.

Linked Accounts

Pairing two sites does not enable replication for all workloads by default. VMease uses linked accounts to give you more control.

A linked account connects a source account to a DR account. This sets clear boundaries for administration and tenancy during disaster recovery.

Linked accounts let VMease handle multisite disaster recovery while keeping tenants separate.

Network Mapping for DR

A replicated VM needs the correct network setup before it can start at the DR site. VMease supports clear network mapping for this reason. For each protected workload, source networks are matched to DR networks, so VMease knows which network to use if a VM starts at the recovery site.

A network map can include:

• A production DR network, used during a real failover.
• An optional sandbox network, used during failover testing.

This distinction is important because it allows operators to test recovery without placing test VMs on live DR networks or risking IP conflicts with production systems.

Sandbox Networks

Sandbox networks are used for non-disruptive failover tests.

During a failover test, VMease can set up a recovery candidate on isolated or controlled networks instead of the live DR network. This allows operators to check recovery steps, boot processes, application dependencies, and VM settings without performing a full production failover.

Where sandbox mappings are configured, VMease uses them by design for test recovery flows.

Replication Jobs and Streams

When replication starts for a VM, VMease creates the necessary replication job and records for each disk. It also saves the VM's build details, such as CPU, memory, firmware, disk, and network setup, for recovery.

Each replicated disk is handled as a stream. The source site mirrors disk writes to the DR-side replication proxy, which writes them to the target storage. This method enables continuous replication instead of just scheduled snapshots.

After the initial sync, new data is mirrored to the DR site, ensuring it always has a recent copy for recovery.

The replication system also monitors job health, stream status, lag, host changes, and recovery points so operators can see the current protection level.

The Replication Proxy

The VMease replication proxy is a VM running on the DR infrastructure. It manages the data side of replication.

At a high level, the replication proxy:

• Receives disk replication streams from the source site.
• Writes replicated data to DR-side target volumes.
• Maintains journal data for recovery consistency.
• Creates and tracks checkpoints.
• Exposes stream and checkpoint status back to the multisite control plane.
• Supports recovery views used for failover and failover testing.
• Helps clean up temporary recovery artefacts after tests or cancelled attempts.

A replication proxy is installed on the hosts to quickly write replicated data to local DR storage. The proxy is shared across multiple streams and is not limited to a single customer or site.

The multisite manager controls the proxy using a dedicated control interface. This keeps main operations in the control plane and lets the proxy focus on managing streams, journals, checkpoints, and recovery data.

Journal and Checkpoints

Journal

The journal records recovery-related write information while replication is active. Its purpose is to support controlled recovery views and checkpoint lineage.

The replication proxy manages the journal and controls how long data is kept. Old data is deleted based on set age or size limits to prevent unlimited growth.

By default, data is kept for 4 hours or up to 5GB.

Checkpoints

Checkpoints represent consistent recovery markers within a replication job.

They are generated by the DR-side replication proxy when the replication streams are healthy. This way, the DR site keeps its own recovery records instead of relying only on the source site, but both sides can display a consistent view of available recovery points.

Checkpoints give users and administrators several RPO options during failover. Depending on the situation, it may be better to select newer or older recovery points.

Failover Testing

Failover testing is meant to be safe and non-destructive.

When an operator starts a failover test, VMease creates a separate recovery candidate using the replicated VM data. If sandbox network mappings are set up, the test candidate is attached to those networks instead of live DR networks.

This allows operators to test the recovery process without stopping the source VM, interrupting replication, or placing the recovered VM on live DR networks.

A failover test is useful for:

• Confirming the replicated VM can boot.
• Validating operating system and application behaviour.
• Checking network attachment logic.
• Testing DR runbooks.
• Demonstrating recoverability to customers or auditors.

Because this is only a test, the result is not made live. After the test, the test VM and any temporary files are removed.

Real Failover

A real failover is the actual recovery process used in production.

During a real failover, VMease creates a DR recovery candidate using the replicated data and connects it to the mapped live DR networks. The system uses the replicated VM configuration and DR-side recovery metadata to bring up the workload in the recovery site in a controlled sequence.

The failover process is automated, not manual. VMease coordinates all the needed steps across the source site, DR site, replication proxy, storage, VM details, and network mappings.

At failover time, VMease is responsible for coordinating:

• Selection of the recovery candidate.
• Use of available checkpoint or recovery data.
• DR-side VM materialisation.
• Network attachment using mapped DR networks.
• Candidate state tracking.
• Operator decision points for cancel or commit.
• Final promotion when the operator commits the failover.

This setup provides a controlled recovery process instead of relying on many separate manual steps.

Cancel or Commit

Cancel

A failover attempt stays as a candidate until the operator decides what to do.

If the operator cancels, VMease stops the current candidate and removes any temporary recovery data. This happens if recovery is not needed, the operator is not ready, or the test or failover should be stopped.

For failover tests, cleanup removes the temporary test VM and files, but keeps the main replication setup intact.

Commit

If the operator commits the failover, VMease promotes the DR-side candidate into the authoritative recovered workload.

Promotion means the DR candidate becomes the accepted recovery result. In real failover, this is the cutover point. Test candidates are not promoted; they are just for validation and are cleaned up after testing.

This commit or cancel approach gives users and administrators the ability to verify a failed-over VM and start another failover with a different RPO if needed. This gives operators clear control during disaster recovery.

Orchestrated Recovery Lifecycle

VMease disaster recovery is designed as an orchestrated lifecycle. It is built as a managed process, not just a one-time script.

1. Mapping source networks to DR networks.
2. Optionally mapping sandbox networks for tests.
3. Starting replication for selected workloads.
4. Maintaining ongoing replication health and checkpoint visibility.
5. Running non-destructive failover tests.
6. Starting real failover when required.
7. Cancelling or committing the failover candidate.
8. Cleaning up temporary test or recovery artefacts.

This approach gives operators consistency and control. It also lowers the risk of missing steps during a high-pressure recovery event.

Operational Monitoring

The multisite manager runs background tasks that keep replication and site status up to date. These include:

• Replication monitoring
  • Watches the replication job lifecycle.
  • Detects failed source jobs.
  • Tracks source host changes.
  • Refreshes RPO-related status.
• Replication proxy provisioning
  • Ensures replication proxy VMs are deployed and configured where required.
  • Supports replacement or redeployment of proxy infrastructure.
• Remote site heartbeat
  • Maintains liveness and authentication status between paired sites.
  • Gives operators visibility of whether the remote site is reachable and ready.

The replication proxy also handles background tasks such as stream supervision, journal refresh, journal retention, autonomous checkpoint creation, and startup reconciliation after daemon restarts. These activities help VMease keep the replication environment running smoothly without constant user input.

Recovery Posture

VMease replication is designed to give virtual machines strong disaster recovery with a low recovery point objective (RPO).

During normal operation, recovery points depend on replication lag, checkpoint timing, status updates, and network conditions. The system is designed for near-continuous replication rather than just periodic backups.

Recovery time varies by the recovery method. Failover tests usually start quickly since they are just for validation. A real production failover takes longer because it requires more steps, such as orchestration, setup, network connectivity, and promotion.

The main point is that VMease manages disaster recovery as a coordinated process. It uses saved VM settings, replicated data, checkpoints, linked accounts, and network maps to recover workloads consistently.

Summary

VMease replication and disaster recovery combines multisite coordination, continuous block replication, DR journaling, checkpoint management, network mapping, sandbox testing, and managed failover.

It is designed for operators who need more than basic backup restores. VMease offers a practical way to protect workloads across sites, test recovery safely, and run controlled failovers when needed.

The result is a disaster recovery model that is easy to control and test, and meets the real needs of infrastructure teams.