Backup Success Is Not Restore Success
Green backup jobs do not answer whether the business can be reconstructed — dependencies, secrets, DNS, integrity.
Backup and restore is discussed in architecture reviews and post-mortems, often as a reliability topic or a FinOps exercise. The conversation stops at policy slides. Constrange's Observe → Measure → Model series treats it as an engineering economics problem: what does the system actually do, what does that work cost, and what model explains the gap between intent and invoice.
Observe: run restore drills to a clean environment. Green backup jobs are necessary, not sufficient.
Measure: time to transactional business function — login, order, payout — not tarball extracted.
Model: restore = data + secrets + DNS + dependencies + integrity checks + runbooks. Backup covers data slice only.
The green job lie
Backup dashboard shows success for 400 days. Restore drill fails: KMS key in wrong account, Terraform state stale, service mesh certs expired, feature flag defaults wrong. The business cannot reconstruct Tuesday from Sunday's snapshot.
What backups do not capture
| In backup? | Restore needs | |
|---|---|---|
| Database dump | Often | Correct version, migrations |
| Secrets | Rarely | KMS, rotation state |
| DNS | No | Registrar, TTL, health checks |
| IAM | Partial | Roles recreated correctly |
| Dependencies | No | Third-party keys, queues |
Measure RTO and RPO on business outcomes. Document dependency order for restore. Automate drill environment provisioning so drills are cheap enough to run often.
Drill programme
- Quarterly restore to isolated account
- Script business smoke tests post-restore
- Track gaps in a living runbook
- Rotate secrets used only in DR
“Backup is a snapshot. Restore is a system reconstruction project.”Constrange
Questions for your next review
- What would we see if we measured restore readiness for one week?
- Which dependency owns the majority of the cost or delay?
- What policy or architecture assumption does the data contradict?
- What is the smallest experiment that would change our model?
The organisations that improve restore readiness are not those with the best slogans. They are those that observe honestly, measure without vanity metrics, and update the model when the bill or the trace disagrees with the diagram.
Frequently asked questions
Are green backups enough?
No — restore drills expose missing secrets, DNS, dependencies, and data integrity gaps.
How often should we test restore?
At least quarterly for critical paths; after major architecture changes.
What fails in restore drills?
IAM, KMS keys, cross-region replication lag, undocumented dependencies, runbook gaps.
What should we measure?
Time to restored business function, not time to mounted volume.