BACKUP EVIDENCE / RESTORE-TESTED

Restore-tested backups: what “tested” should actually mean

UPLOAD IS NOT RECOVERY · RESTORE THE FILE · KEEP THE RECEIPT

A backup is only a promise until you restore it. The dangerous version of backup monitoring says the job ran and an object exists in storage. That is useful, but it is not recovery. A restore-tested backup goes further: it proves the file can rebuild a working Postgres database before anyone needs it during an incident.

The minimum standard

What “backup verified” often misses

Upload verification

  • Confirms a file exists in S3/R2/B2.
  • May check size, checksum, or encryption metadata.
  • Does not prove Postgres can restore it.
  • Does not show how long recovery takes.

Restore testing

  • Replays the actual recovery path.
  • Catches corrupt archives, missing roles, bad extensions, and version problems.
  • Records row counts and restore duration.
  • Creates evidence for auditors and security questionnaires.

The manual version

createdb restore_check
pg_restore --clean --if-exists --no-owner   --dbname restore_check prod_2026-06-14.dump
psql restore_check -c "select schemaname, relname, n_live_tup from pg_stat_user_tables order by n_live_tup desc limit 20;"

That is enough to catch many bad backups, but it only helps if someone runs it every time. The maintenance burden is why teams skip restore testing even when everyone agrees it matters.

How OffsiteDB handles it

OffsiteDB treats restore testing as the core product, not a best-practice footnote. Every snapshot is dumped, sealed, shipped to your bucket, restored into a scratch Postgres, counted, timed, and only then marked proven. The monthly report turns those drill results into the answer for security reviews: yes, our backups are tested; here is when, how long it took, and what was restored.

Need backup evidence you can hand over?

See the sample restore-drill report, run the SOC 2 restore checklist, or start a free trial and let OffsiteDB generate the evidence automatically.

FAQ

What is a restore-tested backup?
A restore-tested backup is a backup artifact that has been restored into a real database environment and checked before it is treated as good. For Postgres, that means pg_restore or psql succeeds, expected schemas/tables exist, row counts are captured, timings are recorded, and the evidence is kept.
Is checking that a backup file exists enough?
No. Object existence proves upload, not recovery. A corrupt dump, missing role, bad extension, incompatible pg_dump version, or truncated archive can all sit in storage looking successful until restore day.
How often should backups be restore-tested?
For production customer data, every snapshot should be tested automatically if the database is small to medium. At minimum, test a representative backup on a schedule and always test a checkpoint before risky migrations.
What evidence should I keep for SOC 2 or a security review?
Keep the backup policy, schedule, retention window, last successful backup, last successful restore drill, restore duration, table/row counts, failures, remediation notes, and a responsible owner. A monthly report is the easiest form to hand over.