Recovery engine

The recovery side of the platform acts on the recovery checkpoints that replication finalizes: it rebuilds protected workloads as native instances of the target platform — a vSphere VM becomes a native EC2 instance, an EC2 instance becomes a native VMware VM — for test recovery, full recovery (failover), and migration.

Recovery workflow stages

Recovery workflows include:

1. Checkpoint selection

   The operator recovers from the latest consistent replicated copy or a point-in-time checkpoint. When a PIT copy is used, the recovery configuration captured with that checkpoint is applied.

2. Disk reconstruction and snapshot finalization

   Disks are reconstructed from the checkpoint through the target platform's native storage — AWS EBS snapshots and volumes, Azure Managed Disks, VMware datastores, GCP Persistent Disks.

3. System health checks for Windows workloads

   Windows recoveries are prepared and validated by the Prep Node — boot remediation, file-system and registry compatibility checks. Prep Nodes power on only for this work. Linux recoveries are handled by the management and replication nodes directly.

4. VM instantiation and network attachment

   The instance is created with the per-VM recovery configuration from the protection plan — instance type, storage, networks, IPs, security groups — optionally installing system agents and cloud SDKs into the guest.

5. Boot order orchestration

   VMs boot in the plan's configured order with the configured delays, so dependent tiers come up correctly.

6. Recovery validation

   Windows guests run a validation step; recovered IPs are surfaced on the recovery job for RDP/SSH verification. Pre/post recovery scripts hook the workflow at plan and VM level.

Recovery modes

The same engine drives all recovery patterns: full site failover, partial failover (a subset of VMs), test failover into isolated networks, cross-cloud recovery, and granular workload recovery — plus migration as a final cutover and reverse replication for the return trip.

What makes the 10-minute SLA possible

• Cloud-native recovery — recovery builds directly on the target platform's compute and storage APIs, with no intermediate hypervisor or staging layer to convert through.
• Finalized checkpoints — replication iterations end in validated, recovery-ready checkpoints, so failover starts from consistent state rather than assembling one.
• Parallel orchestration — recovery operations run in parallel while respecting cloud API limits, quota constraints, and storage concurrency; each Prep Node handles up to 20 parallel Windows recoveries, scaling horizontally per AZ.

Scaling recovery

Recovery concurrency depends on Prep Node attached-disk capacity, cloud API throttling, compute instance quotas, and network provisioning concurrency. Plan recoveries in batches aligned to protection plans, and pre-validate target-cloud quotas — see Limits and the Scale and performance guide.

Related docs

• Replication engine

• Failover workflow

• Recovery testing

• Preparing target site