01
A green backup job is not proof of recovery. Corrupted artifacts, wrong secrets, schema drift, and stale drills still leave you unready when production disappears.
Case 03 · Flagship
Kanister Backup & Restore
Recovery Contract for Kubernetes: backups are restored, verified against measurable objectives, and marked PROVED or UNPROVED before an incident — not assumed after pg_dump succeeds.
01
How it works
From backup to a Recovery Contract.
Recovery Contract by Andrey Lesnikov — protect, validate, restore, and prove recoverability before the incident starts.
-
01
Protect
Application-aware backup via Kanister Blueprint — real pg_dump, object-store artifact, ActionSet evidence.
-
02
Validate
Prove artifact integrity (gzip / SQL head) before trusting the object — creation alone is not enough.
-
03
Restore
Isolated namespace drill with health checks and recovery markers — not a hope that PVC bytes were enough.
-
04
Prove
Evaluate the Recovery Contract. Verdict is PROVED or UNPROVED with RTO, RPO, and freshness — never a percentage score.
02
Evidence
From problem to proof.
How the system is framed, operated, and proven — not a slide deck summary.
02
Kanister executes Blueprints and ActionSets. This layer adds PROTECT → VALIDATE → RESTORE → PROVE: a Recovery Contract with binary verdict, measured RTO/RPO, and optional failure drills.
03
Continuous proof costs cluster time and design effort. The payoff is PROVED or UNPROVED with an explicit reason — not a decorative percentage.
04
Multi-service contract: one recovery point covers Postgres + S3 objects, and PROVE requires both components restored plus cross-component consistency (checksums, bounded skew). recovery_point_skew_seconds_max is fail-closed (PR #23): skew above the ceiling, or missing/null skew on multi-service evidence, is UNPROVED with reason recovery_point_skew. Recovery Drill on kind: PROVED with RTO 8 s on k8s v1.37.0 and 8 s on v1.36.4 (ceilings RTO ≤ 60 s, skew ≤ 60 s; docs/results.md / docs/EVIDENCE.md); failure drills delete-s3-object, corrupt-s3-object and mismatched-recovery-points each end UNPROVED with a named reason (run 38131463362). Kind lab numbers, not production-scale RTO.
Constraints
Application-aware Kanister workflows, isolated drills, Recovery Contract clauses, and deliberate failure scenarios.
03
Related
Nearby systems.
Automatic SaaS Restore System
Restores are high-pressure, manual, and easy to execute inconsistently
Recovery as a platform capability
Self-Healing Infrastructure
Transient infrastructure failures can become user-facing incidents when recovery depends on manual detection
Common failures recover with guardrails
BlastGuard
CVE scanners produce finding counts
Blast radius predicted before CVE count
04
FAQ
Questions operators ask.
A measurable prove of recoverability. Backup success is PROVED or UNPROVED against artifact integrity, isolated restore, application readiness, data verification, RTO, and evidence freshness.
Percentages invite fake precision. A binary contract with an explicit Reason is easier to operate and audit.
make failure-drill SCENARIO=corrupt-artifact (and siblings) injects known failure modes so you can see UNPROVED with a clear blocked clause.
Available for meaningful infrastructure conversations