Most backups have never been restored

Ask your team when they last tested a restore from backup. Not when the backup last ran. When someone pulled the artifact, ran the restore, and confirmed the database was usable.

Most can't answer. The ones who can usually say "during the last migration" or "when we first set it up."

That's the state of the industry. Not "we don't have backups." Everyone has backups. The cron job runs. pg_dump writes to S3. The managed provider takes snapshots. The monitoring is green.

But the monitoring watches the backup. Not the restore. The green checkmark means the upload succeeded. It says nothing about whether those bytes would produce a working database if you needed them tomorrow.

Schemas drift. Extensions get added. Postgres major versions bump. Collation settings change after an OS upgrade. The backup from last Tuesday uploaded fine. The restore would fail.

The entire backup ecosystem is oriented this way. Providers sell retention windows and snapshot frequency. Monitoring tools check whether the job ran. Dashboards show green. At no point does anyone run the restore and verify the result.

So teams automate the backup and move on. Six months pass. A year. The last person who tested a restore has left the company.

The gap isn't backup. It's verification.

I'm building Restorable to close it. Automated restore tests, weekly. Each one produces a signed receipt your auditor can verify independently against your public key. The receipt is the deliverable, not the backup.

The architecture (EU-sovereign, customer-held keys, open-source agent) follows from one constraint: we can't read your data. I'll write about each of those decisions. But the starting point is this: your backup should prove it can restore, and someone other than you should verify it.