| Environment | Last backup | Covers | PITR | Last restore test | Status | |
|---|---|---|---|---|---|---|
| meridian-health / prod | today 09:00 verified | 3 DBs tfstate state secrets inv. | 14d | 6d ago · RTO 11m passed | restore-tested | |
| kestrel-bank / prod | today 09:10 verified | 3 DBs tfstate state secrets inv. | 30d regulated profile | 12d ago · RTO 16m passed | restore-tested | |
| osaka-robotics / prod | today 08:52 verified | 3 DBs tfstate state secrets inv. | 14d | 34d ago · RTO 13m due | test overdue | |
| verde-foods / prod | today 09:04 verified | 3 DBs tfstate state secrets inv. | 14d | 31d ago · RTO 12m due | test overdue | |
| northwind-logistics / prod | today 09:02 verified | 3 DBs tfstate state secrets inv. | 14d | 9d ago · RTO 14m passed | restore-tested | |
| cobalt-mining / prod | on-site 02:00 verified as of bundle · 3d ago |
3 DBs state secrets inv. | 7d local media | 18d ago · RTO 21m passed executed on-site · journal via bundle |
restore-tested | |
| …8 more environments | all backed up < 24h · all restore-tested < 30d | |||||
| Objective | Target | Measured | |
|---|---|---|---|
| RPO — data loss window | ≤ 15m | 4m (PITR replay lag, worst case 30d) | meets |
| RTO — single environment | ≤ 4h | 11–21m (range across 14 restore tests) | meets |
| RTO — full region failover | ≤ 8h | 2h 40m (drill 2026-06-30, simulated) | meets |
| Backup verification lag | ≤ 24h | ≤ 4h (checksums + manifest, air-gap via bundle) | meets |
A production restore is a plan like any other: pick the environment and point-in-time, the engine renders exactly what will be overwritten, and the plan requires a typed confirmation plus an approval token. Backup-before-destructive applies to restores too — the current state is snapshotted before the restore begins.
Target environment:
The test restores last night's verified backup into an isolated scratch namespace, verifies row counts + schema fingerprints, runs the product smoke hooks, then destroys the scratch copy. Production is never touched.
Estimated 15–25 min · no downtime · result lands in the posture table and the audit trail.
This renders a plan to restore exactly this point-in-time:
RESTORE point-in-time 2026-08-05 13:45:00 UTC (12 min before drift change) TARGET 3 databases · engine state · configuration v41 FIRST snapshot current state → restore point pre-restore-8843 LOSES all writes after 13:45 — the plan lists affected row estimates
Type restore to render the plan: