Recovery engine

The recovery engine is the component of Datamotive responsible for executing failover and failback operations. It works alongside the replication engine: while the replication engine continuously synchronizes data, the recovery engine acts on that data when a failover is triggered.

How the recovery engine works

The recovery engine maintains a ready-to-boot state for every protected workload. When a failover is triggered, the engine executes four stages:

1. Select a recovery point — The operator chooses the recovery point to restore from (most recent or a specific earlier point). For production failovers, the most recent consistent point is used. For ransomware recovery, an earlier clean point can be selected.

2. Attach shadow disks — The shadow VM at the target already exists and has its disks pre-attached. The recovery engine finalizes the disk attachment from the chosen recovery point, which is a near-instant operation.

3. Apply network customizations — Before the VM boots, the engine injects network settings (hostname, IP address, DNS server, gateway) using a lightweight boot-time agent that runs for a few seconds on first start. This agent is compatible with all verified guest OS families.

4. Boot the VM — The shadow VM powers on. For most OS types, boot completes in under 90 seconds. The engine monitors the VM's heartbeat and marks the failover complete when the guest OS reports healthy.

Why RTO is under 10 minutes

The sub-10-minute RTO comes from the pre-built state maintained by the replication engine:

• Shadow VMs are created at the target during plan activation, not at failover time. Creating a cloud VM from scratch takes 3 to 8 minutes; Datamotive eliminates this wait.
• Disks are pre-attached and pre-populated. There is no data copy at failover time.
• Network customizations run in parallel across all VMs in the plan, not sequentially.

The 10-minute window covers: recovery point selection (operator action, typically under 1 minute) + disk finalization (under 30 seconds) + VM boot and OS startup (1 to 3 minutes) + network customization injection (under 1 minute) + application startup (varies by workload).

Failover ordering

Within a plan, VMs are organized into groups. The recovery engine starts groups sequentially in the configured order, but boots all VMs within a group in parallel. This allows database VMs to be fully up before application-tier VMs receive traffic.

Failback

Failback reverses the replication direction. Once workloads are running at the DR target, the recovery engine:

1. Starts a reverse replication cycle: tracking changes made at the target and streaming them back to the source.
2. On the cutover day, quiesces the target VMs and takes a final sync.
3. Brings the source VMs back online with the latest data from the target.

Failback does not require a new bootstrap. Only the blocks changed during the failover period are transferred back, which is typically much smaller than the original dataset.

Related docs

• Replication engine

• Orchestration

• Failover workflow

• Failback workflow