Backup verification: restore it, then count what came back
A backup job that exits 0 tells you the job exited 0. The checks that tell you a backup will restore are the ones that restore it. SafeGrd restores each backup on a schedule, compares every table and row with what was backed up, and signs a dated record of the result. We call each of these a Fire Drill.
Run your first Fire Drill How Fire Drills work
What each kind of check proves
| Check | Catches | Misses |
|---|---|---|
| Checksum of the stored file | A lost or altered upload | A dump that was wrong or incomplete when it was written |
| Reading the archive to its end | A file cut short by a full disk or a broken pipe | Data that will not load into a server |
| Counting rows against the backup's manifest | Tables or rows missing from the backup | Schema the target server rejects |
| Loading it into an empty database | All of the above, plus missing extensions, roles and syntax the server rejects | A backup of the wrong database, if nobody looks at the counts |
SafeGrd's in-memory drill does the first three without a database server. Its sandbox drill does all four, in a throwaway database it creates and drops. The guide to testing a restore shows how to run each level by hand.
What a Fire Drill checks, per database
| Database | The drill checks |
|---|---|
| PostgreSQL | Table, row and column counts and installed extensions against the manifest. A sandbox drill also loads the schema, constraints and triggers. |
| MySQL and MariaDB | The dump's end marker, table structures and row counts. A sandbox drill loads it into a scratch database. |
| MongoDB | The archive's end, document counts and collection checksums. A sandbox drill restores it with mongorestore and counts each collection. |
| SQLite | A full restore to a temporary file, PRAGMA integrity_check, and each table's rows. |
Files and mailboxes are drilled too. Every restored file must match its SHA-256, and every message must parse as mail and match its SHA-256 (Surfaces).
How often
Every plan runs scheduled drills. The plan sets how often and how far the restore goes:
- Free: monthly, checked in memory
- Starter: weekly, loaded into a throwaway database
- Growth: daily, loaded into a throwaway database
- Scale: daily, loaded into a throwaway database
What you get from each drill
- A signed record. What was restored, when, on which host, and every check with its result. An auditor can verify the chain of records offline with SafeGrd's public signing key (Attestation).
- An alert when a drill fails or runs late, to a webhook, Slack or Discord, and by email on paid plans.
- A badge for your README, green while drills pass, amber when one is late, red when one fails.
- A known-good snapshot. Threat Shield compares each backup with the one before it and marks a backup where tables vanished or most rows went, so a destructive change does not become the backup you trust (Threat Shield).
Questions
Does a drill touch the production database?
A drill reads the backup from storage and restores it somewhere disposable. It never connects to the database the backup came from, and it refuses a target that already holds tables.
Is this enough for SOC 2 or ISO 27001?
The records are evidence that restores are tested on a schedule, which auditors ask for. They are not a certification. Backup controls lists which record answers which question.
Related
- Backup file checker: the first two checks, on a file you have, in your browser
- PostgreSQL backup, MySQL backup and MongoDB backup
- Restore and Fire Drills: commands and options