Skip to main content

​
Overview

Recovery plans define the complete failover procedure — which resources are protected, in what order they recover, what health checks confirm readiness, and what automation scripts run at each stage. A well-designed recovery plan is the foundation of a reliable DR strategy with predictable RTO.
Prerequisites
  • Sites registered and replication link verified (see Replication Configuration)
  • Administrator credentials on both sites
  • Instances and volumes to protect must exist in the project

​
Creating a Recovery Plan

Open Recovery Plans

Navigate to Disaster Recovery → Recovery Plans → Create Plan.

Define plan parameters

Add resource groups

Organize protected resources into ordered recovery groups. Resources within a group recover in parallel; groups recover sequentially.
Model recovery groups on the actual application dependency chain. Starting an application server before its database is ready causes service errors and may require manual intervention during a real failover.

Configure automation hooks

Add pre/post scripts to each resource group:

Set health check criteria

Define what “recovered” means for each resource group:
  • HTTP health check — URL and expected response code
  • TCP port check — host and port number
  • Script — custom validation command (exit 0 = healthy)
A recovery group advances to the next group only when all health checks in the current group pass. This prevents cascading failures where dependent services start before their dependencies are ready.

Activate the plan

Click Activate. XDR begins replicating all protected resources to the DR site. Initial sync time depends on data volume.
Plan status shows ACTIVE and initial replication sync progress is visible in the replication dashboard.

​
Managing Existing Plans

Navigate to Disaster Recovery → Recovery Plans to see all plans with their current status and replication lag.Available actions per plan:
  • Edit — update RPO/RTO targets, add/remove resources, modify health checks
  • Deactivate — pause replication without deleting the plan
  • Delete — permanently remove the plan (stops replication)
  • Failover — initiate failover (see Failover)
  • Test Failover — run an isolated DR test without cutting over production traffic

​
Consistency Modes

Use application-consistent mode for databases and transactional workloads. Crash-consistent mode is suitable for stateless compute instances where data integrity depends on the application rather than the storage layer.

​
Recovery Point Retention

XDR retains a configurable number of recovery points, allowing historical restore targets during failover: Configure retention settings from Disaster Recovery → Recovery Plans → [Plan] → Retention:
Increasing recovery point retention consumes additional storage on the DR site. Each recovery point is an incremental snapshot — for high-change workloads, deep retention can accumulate significant storage overhead.

​
Next Steps

DR Automation

Configure runbook scripts and automatic failover triggers

Monitoring

Monitor plan replication health and RPO adherence

Compliance

Generate RPO/RTO compliance reports from plan history

XDR User Guide — Protection Plans

User-facing protection plan management