# Evidence-grade data protection.

Tamper-evident snapshots with Merkle-linked evidence chain. Recovery SLOs continuously verified by synthetic restore drills — not at audit time. Restore is a ChangeSet: simulation, blast-radius assessment, tested rollback, executed under policy.

## Snapshots hash upward.

Every snapshot is a leaf. Pairs hash together into internal nodes. The root is signed with the tenant's Ed25519 key (KMS-wrapped). Tampering anywhere is detectable from any cut point.

ROOTh1h2h1.1h2.2h3.3h4.4a83f9bb51da3c812d5d94f2ee74b8af0a4498f24c15d39c0▼ snapshots · leaf hashes▲ root · sha-256 · ed25519 signed

SHA-256  
* snapshot hash  
Ed25519  
* signing key  
KMS  
* envelope wrap  
Merkle  
* cross-link  
* daily  
* restore drill  
* 15min  
* default RTO  
* <1s  
* hot-standby RPO  
* ∞  
* audit retention

## Restore confidence measured continuously.

Every 24 hours, a synthetic restore drill picks a random snapshot from the last 30 days. The full path runs: integrity check → policy gate → restore → boot the workload → verify. Drift surfaces in /status before customers notice.

Restore isn't an emergency procedure. It's a planned operation under the same ChangeSet engine as every other platform mutation.

#### Snapshot select

Daily synthetic restore drill picks a random snapshot from the last 30d.

0.2s

#### Integrity check

Merkle path verified leaf → root. Ed25519 signature checked against KMS public key.

1.4s

#### Policy gate

OPA evaluates: restore allowed in this tenant, this region, this hour?

0.3s

#### Restore execute

Blocks restored to a fresh tenant volume. Real-time progress logged.

12.8s

#### Verify

Workload boots. Health check passes. Compare hash of restored blocks to source.

4.2s

## Live SLO posture +per-snapshot diff.

90-day compliance band shows when SLO is met, drifting, or breached. The snapshot diff makes tampering visible at the file level — added, changed, removed, unchanged with hash comparisons.

### RTO / RPO compliance · last 90 days

* 84 in-SLO  
* 5 drifting  
* 1 breach

90d agoRTO target 15min · RPO target 5mintoday

### snapshot diff · tnt-a · 24h window

* +2 added  
* ~2 changed  
* -1 removed  
* ·3 unchanged

~/etc/nginx/nginx.conf  
8f3a2c…b7c1d9…  
·/etc/nginx/sites/api.conf  
a52b1e…a52b1e…  
~/etc/systemd/system/api.service  
4d8f17…c419fa…  
+/var/lib/app/db/migrations/0042.sql  
—e2b48d…  
·/var/lib/app/db/migrations/0041.sql  
5740c1…5740c1…  
-/var/lib/app/cache/build-tmp-xyz9a8d3f…—  
·/var/log/api/2026-05-19.log  
31b274…31b274…  
+/var/log/api/2026-05-20.log  
—7e51c2…

## The chain spans product boundaries.

When MSP detects an incident, the response can invoke a Backup restore. Both events chain into the unified tenant audit log. One root hash spans the whole response — not three separate vendor logs.

#### Incident detected

Identity Exposure agent flags credential breach on endpoint e_8a4f.

```  
ts: 14:23:41.082  
ev: msp:evd:a83f9b…  
cs:  ISOLATE_ENDPOINT  
```

#### Restore triggered

CONTAIN_LATERAL ChangeSet invokes restore of clean snapshot for the isolated endpoint.

```  
ts: 14:23:44.512  
ev: bk:evd:c419fa…  
cs:  RESTORE_SNAPSHOT  
```

#### Chain merged

Cross-product evidence chain: MSP root → Backup root → unified tenant audit log.

```  
ts: 14:23:44.601  
ev: audit:root:8f24c1…  
cs:  —  
```

## Per-workload, per-recovery-mode.

Choose cold archive, warm replica, or hot standby per workload. Operating mode is a tenant setting; switches between modes are evidence-chained ChangeSets. No vendor lock-in to one recovery posture.

### Cold archive

Lowest cost, hours RTO.
* RTO hours  
* RPO 24h  
* Cost $

// Whole tenant lost ≤ 24h prior

Suited for
* Compliance retention  
* Long-tail audit storage  
* Rarely-restored workloads

### Warm replica

Balanced cost, minutes RTO.
* RTO minutes  
* RPO 15min  
* Cost $$

// Per-workload lost ≤ 15min prior

Suited for
* Default for most workloads  
* Production app data  
* Multi-tenant SaaS substrate

### Hot standby

Highest cost, seconds RTO.
* RTO seconds  
* RPO <1s  
* Cost $$$

// Near-zero data loss; auto-failover

Suited for
* Critical-path infra (auth, identity)  
* Billing surfaces  
* Cross-region active-active

## Different data structure. Not different storage.

### Snapshot integrity

| Traditional backup    | Brainstorm Backup                                                                 |
|-----------------------|----------------------------------------------------------------------------------|
| Take snapshot. Trust the vendor. | SHA-256 hash + Ed25519 signature at capture time. Merkle link from leaf to root. Verifiable end-to-end. |

### Restore confidence

| Traditional backup    | Brainstorm Backup                                                                 |
|-----------------------|----------------------------------------------------------------------------------|
| Test restore "occasionally" — usually after an incident exposes a stale backup. | Synthetic restore drill runs every 24h on a random snapshot. RTO/RPO compliance graphed across 90 days. |

### Restore operation

| Traditional backup    | Brainstorm Backup                                                                 |
|-----------------------|----------------------------------------------------------------------------------|
| Operator invokes restore tool, hopes it works, watches a progress bar. | Restore is a ChangeSet — Intent → Simulation → Policy gate → Execute → Verify. Same engine as every other platform mutation. |

### Audit trail

| Traditional backup    | Brainstorm Backup                                                                 |
|-----------------------|----------------------------------------------------------------------------------|
| Backup tool log. Vendor-specific format. Best-effort retention. | Evidence chain spans products — MSP incident → Backup restore → audit log root, all signed and linked.

## Operate the chain.

Open the operator console to inspect snapshots, replay the chain, run restore drills.