# Storage and recovery relationships

## Purpose and scope

This diagram separates local storage availability, application-backup evidence,
off-site configuration inventory, and restore targets. These layers address
different failure domains and are not interchangeable.

- **Source:** `sources/storage.mmd`
- **Generated output:** `generated/storage.svg`

![Sanitized storage relationships](generated/storage.svg)

## Components and ownership boundaries

Applications own consistency before writing through PVC/PV interfaces.
Longhorn owns local volumes, snapshots, and replicas. Velero records Kubernetes
application-backup state in the inspected environment. A separate CronJob owns
an age-encrypted, allowlisted configuration export to private Cloud Storage.
Cloud storage and lifecycle policy cross the cloud trust boundary; target
preparation, restore approval, and application checks remain operator-owned.

## Data flow and failure paths

The stateful path is workload → PVC/PV → Longhorn primary/replicas. The observed
application-backup path is separate and was reported in-cluster by the dated DR
assessment. The off-site path is allowlisted Kubernetes configuration—with no
Secret-object query and only ConfigMap names/keys retained—→ encryption → upload
→ retention → decrypt-and-list inspection. Selected workload specifications
remain and may contain literal values, so the archive is still sensitive.

Replica loss, unhealthy volumes, failed snapshots/backups, a same-domain backup
target, failed federation/upload, unreadable archives, missing application data,
or an untested restore each requires separate evidence and remediation.

## Omissions and verification

The off-site archive does not contain persistent volumes, databases, application
data, or a complete cluster. Disk IDs, bucket/object names, data values,
credentials, and retained contents are omitted. Longhorn manager v1.12.0,
Velero v1.18.1, and the configuration CronJob last-success time were observed
read-only on 16 July 2026. On 24 July, all 10 PVs and 10 PVCs were Bound, but
the newest node still had an unready Longhorn integration. Velero showed eight
Completed records and 22 failed, validation-failed, partially failed, or still
finalizing records; the newest completed critical-workload run was dated
22 July, so current off-site success is not claimed. The private GCP backup
bucket controls were verified that day. Decrypt-and-list remains a 15 July
record with no resource apply or application restore.

Use it with the [backup and restore flow](backup-restore.md) and
[disaster-recovery overview](disaster-recovery.md).

Regenerate and validate with `npm run diagrams && npm run diagrams:check`.