The backup loop that proves the dump will load.
A backup that only proves a file exists is not enough. The failure that matters is the one discovered on disaster day: a missing extension, truncated dump, version mismatch or row count that no longer matches production.
How these were measured: Source: operations/systems/K-16-backup-cold-com-kratt-backup-cold.md and K-17-restore-test-com-kratt-restore-test.md record the build dates, green runs, retention, restore behavior and known exception.
What we shipped
backup-cold dumps the operational stores that would hurt if the box died and verifies row counts against the same run. restore-test then loads those dumps into a throwaway Postgres instance on a separate machine, checks for load errors and matching rows, and destroys the test database after the run.
What this page does not claim
- No database contents, dump paths, host addresses, personal data, Slack webhook or credential material is exposed.
- The n8n backup gap remains stated instead of claimed solved. The source card says the target exists but is blocked on a human approval and encryption-key handling.
- No claim that this replaces a formal disaster-recovery program. It proves these dumps exist, verify row counts and load in a separate restore test.
Where is your business leaking revenue?
A free AI audit finds it, ranked by impact, and it is yours to keep.
Back to all case studies, or see every live build on the portfolio wall.