Overview

XReplicator v1.3.1 provides an Azure-to-Azure disaster recovery workflow from the web UI. Operators enable DR for source disks, keep DR-side staging disks in sync, validate readiness with precheck, trigger Azure VM failover from a blueprint, and then use the failback workflow to return data to the primary VM when the incident is over.

Architecture

The Azure DR flow uses these components:

• Source agents protect Windows and Linux VM disks through block-level backups.
• Backup server stores snapshots and coordinates DR source state.
• DR staging disks are raw Azure disks attached to the DR-side environment and kept current by XReplicator.
• Web UI owns cloud targets, blueprints, precheck, failover, failback, and operation history.
• Azure target config stores tenant, subscription, region, resource group, VNet, subnet, VM size, and credentials.

Prerequisites

Before enabling DR, confirm:

• The backup server and web UI run in the Azure DR landing zone.
• Source agents are connected and completing backups.
• Raw target disks are attached to the DR-side environment and are at least as large as their source disks.
• Target disks are not mounted, read-only, or already assigned to another DR source.
• The Azure service principal can create snapshots, disks, NICs, and VMs in the target resource group and read the target network.
• The target VNet, subnet, route tables, NSGs, and DNS/cutover plan are ready.

DR Page Controls

The DR page is organized into these tabs:

Enable DR for Source Disks

1. Open DR > Sources.
2. Locate each source VM disk that must be protected.
3. Click Enable DR.
4. If this is the first time the source is mapped to a DR target disk, choose how to prepare the newly mapped target disk:
   • Wipe and zero removes filesystem signatures and zeros the beginning and end of the target disk before DR sync starts.
   • Continue without wiping leaves existing signatures in place and starts sync without disk preparation.
5. Wait for the source to become healthy.
6. Use Retry backfill if the initial sync fails after the underlying problem is fixed.
7. Use Check health to verify the source can still reconcile to its desired snapshot.

Use Wipe and zero for newly attached raw DR disks unless you have already prepared the disk out of band. Never select a disk that contains data you need to keep.

Configure Azure Targets

1. Open DR > Targets.
2. Add an Azure target.
3. Enter tenant ID, client ID, client secret, subscription ID, target region, target resource group, network resource group, VNet, subnet, and default VM size options.
4. Save the target and confirm it is available when creating a blueprint.

Keep service principal permissions scoped to the DR resource groups wherever possible.

Create a Blueprint

1. Open DR > Blueprints.
2. Create a blueprint for one protected VM.
3. Select the source client and all disks that make up the VM.
4. Map the row to the Azure target config, region, resource group, network resource group, VNet, subnet, VM size, and optional hostname override.
5. Choose OS and data disk strategies:
   • Attach as-is uses already-synced DR disks directly. This is the fastest measured path.
   • Create from snapshot creates Azure snapshots and new managed disks before VM creation. This is useful when you want the failover VM to run from isolated copies.
6. Save the blueprint.

For Windows Server OS disks, prefer the specialized OS-disk attach path from a snapshot-derived managed disk rather than treating the disk as a generalized Sysprep image.

Precheck and Readiness

Open DR > Failover, select the blueprint, and run precheck before every drill or production failover. Precheck should pass only when:

• DR is enabled for every selected source disk.
• Each source is healthy.
• Applied snapshots match desired snapshots.
• The Azure target config is complete.
• The blueprint row has region, resource group, network, VM size, OS strategy, and data strategy.

Do not trigger failover while sources are pending, backfilling, verifying, or degraded unless you intentionally accept an older applied restore point.

Trigger Failover

1. Open DR > Failover.
2. Select the blueprint.
3. Run precheck and review warnings or blockers.
4. Click Trigger failover.
5. Confirm the operation.
6. Watch row-level logs for source selection, OS disk handling, data disk handling, NIC creation, VM creation, and completion.

Expected logs include messages such as:

• Resolving the OS source disk.
• Creating an OS snapshot or reusing an existing DR OS disk.
• Creating data disk snapshots or attaching existing DR disks.
• Creating a NIC in the configured subnet.
• Creating the recovered Azure VM.
• Completing the row for the target VM.

Validate the DR VM

After failover completes:

• Confirm the VM boots cleanly.
• Confirm OS and data disks are present and mounted as expected.
• Confirm networking, NSGs, routes, DNS, and application dependencies.
• Run application health checks.
• Record VM-created time, OS-ready time, and application-ready time separately.
• Keep the failover operation in history; failback uses that context.

Failback Flow

Use failback after the primary environment is ready to receive data again.

1. Open DR > Failback.
2. Select the completed failover operation for the blueprint.
3. Click Prepare failback so XReplicator resolves the DR VM sources and maps them back to the original primary sources.
4. Review mappings carefully. DR VM disks should be treated as failover DR sources, not new primary sources.
5. Run Check primary disks.
6. Resolve blockers before syncing. Data disks should be unmounted, quiesced, or otherwise safe to overwrite on the primary side.
7. Start failback sync.
8. Monitor progress and logs.
9. Complete failback only after validation passes.

For OS disks, avoid live overwrite of a running primary OS disk. Use the product’s blocked/rescue-mode guidance for OS disk recovery when needed.

RTO Notes

The measured drill numbers are useful for planning but are not guarantees:

The measured workload was one VM with a 30 GB OS disk and a 4 GB data disk. For production planning, measure your own RTO using the same VM size, disk count, region, network, and application startup procedure you will use during an incident.

Operational Checklist

• Run at least one failover and failback drill per protected workload.
• Record attach-as-is and snapshot-based RTO separately.
• Keep source, target, and blueprint naming consistent.
• Keep DR target disks raw and dedicated to XReplicator.
• Rotate Azure credentials and keep permissions least-privilege.
• Document DNS, load balancer, firewall, and application validation steps.
• Review operation history after every drill and fix recurring warnings.

Current Scope

Supported in v1.3.1:

• Azure-to-Azure DR setup.
• DR source enablement and staging sync.
• Target disk preparation prompt.
• Strict precheck.
• Azure target configuration.
• Blueprint-driven Azure failover.
• Attach-as-is and snapshot-based disk strategies.
• Failback preparation, primary disk checks, sync monitoring, and operation history.

AWS and GCP remain documented as cold DR/manual runbook paths unless provider orchestration is added later.