# Disaster-recovery dependencies

## Purpose and scope

This graph explains the dependency order a recovery plan must satisfy. It models
DR-validator reasoning and generic risk patterns, not current defects or a
completed restore.

**Source:** `sources/dr-dependencies.mmd`  
**Generated:** `generated/dr-dependencies.svg`

![Disaster-recovery dependencies](generated/dr-dependencies.svg)

## Components and boundaries

Cluster/control-plane state, persistent data, GitOps bootstrap, authentication,
DNS/TLS, backup storage, restore tooling, and recovery documentation are
separate components. Git, external identity, DNS, and backup targets must remain
usable outside the failed cluster. An operator owns target selection, approvals,
and acceptance checks.

## Data flow and failure paths

Recovery establishes control-plane state, external authentication and Git
access, bootstrap controllers, data access, DNS/TLS, then application services.
The graph flags cycles, backup targets in the same failure domain, credentials
trapped inside the cluster, and backup artifacts without restore evidence.
Those nodes are questions to resolve, not findings that are true by default.

## Omissions and verification

Identifiers, credentials, object contents, current findings, measured RPO/RTO,
and application acceptance criteria are omitted. The validator source and a
read-only protection matrix were reviewed; the matrix is dated 13 July 2026.
Scenario and restore guardrails are source tests, not a live restore. No resource
application is claimed.

Related: `hybrid-cloud/docs/disaster-recovery.md` and the restore runbook.

**Validation:** `npm run diagrams:check`.