Prove your backups restore

A drill is a rehearsal. A fire drill does not fight a real fire — it proves that when one happens, everyone knows the way out. A backup drill is the same idea for your data: rather than waiting for a real outage to discover whether your backups work, you rehearse the recovery on a schedule.

In practice, a backup drill takes a real backup — the dump your database produces every night — restores it into a clean, isolated environment, and checks that the data actually came back intact. When the restore fails, or the data is wrong, you learn it today, in a report — not at 3 a.m. during an incident.

A backup job that reports success tells you one thing only: a file was written. It does not tell you the file can be restored. Backups fail silently, in ways a success status never catches:

• A dump truncated when a disk filled up
• A missing database extension that makes the restore error out
• Schema drift that breaks your application against the restored data
• Expired credentials, leaving the dump effectively empty
• A backup of the wrong database entirely

Each of these passes the backup job and fails the restore. Teams routinely discover a broken backup at the worst possible moment — mid-outage, when that backup is the only thing between them and lost data. An untested backup is closer to a guess than a guarantee.

Every Dokaz drill runs the same six steps, inside an isolated sandbox that never touches your production database:

A green checkmark in a dashboard is worth little to an auditor or an underwriter — they have only your word for it. Dokaz's evidence is different: every drill produces a Proof-of-Recovery PDF that is cryptographically signed, and that anyone can verify without trusting Dokaz at all.

• The PDF records the source, its SHA-256 hash, every assertion's expected-vs-actual result, the restore duration, and the operator.
• It carries a detached Ed25519 signature over the document's digest — change one byte and verification fails.
• The signing public key is published at a stable URL, and an open-source verifier (dokaz-verify) checks any PDF against it offline.
• Evidence is retained for seven years to match the audit window.

To be precise about what this is: the signature proves the evidence is tamper-evident and was produced by Dokaz's key. It is not yet a third-party trusted timestamp (RFC 3161) or a certificate-authority document signature — those are on the roadmap, and we describe the current model plainly rather than overclaim it.

Doing all of this by hand is tedious — so it does not get done. Dokaz turns backup drilling into something that simply happens:

• On a schedule — drills run on the cadence you set, so a broken backup surfaces within days, not during a recovery.
• Isolated and safe — every drill runs in an ephemeral sandbox destroyed when it finishes. Dokaz never connects to your production database.
• Real assertions — go past "it restored" — assert row counts, that key tables and columns exist, and that critical columns contain no nulls.
• Signed evidence — every drill produces a signed PDF and an immutable audit entry, retained for seven years with a live tamper-check.
• In your workflow — a versioned JSON API and signed webhooks push drill results into your own alerting and dashboards.

Dokaz is built for engineering teams running managed PostgreSQL who cannot afford to learn their backups are broken the hard way. It is sharpest for two moments:

• A SOC 2 or ISO 27001 push — recovery testing is an expected control (ISO/IEC 27001:2022 Annex A 8.13; SOC 2 Availability A1.3), and Dokaz's report is drop-in audit evidence.
• A cyber-insurance renewal — carriers increasingly require proof you restored from backup within the last 12 months; Dokaz produces exactly that, dated and signed.