Backup Restore Proof

Four green nights that cannot be restored

Every one of these produces a passing dashboard:

• pg_dump exits 0 having written schema only, because the table filter matched nothing. The
• file is valid. It restores cleanly. It contains no rows.
• The dump is 40 bytes and gzip-valid. Size was never compared to yesterday's.
• Backups have run nightly for a year and nobody has ever restored one. The format changed
• eight months ago.
• Retention deleted the last good copy, because retention counts backups, not **verified
• backups** — and the corrupt ones are newer, so the naive policy keeps exactly the wrong set.

unverified is not verified

That distinction is the module.

  assessBackup(backup, previous, { now });
  // { verdict: "unverified",
  //   reasons: ["never restore-tested — this is an untested claim, not a working backup"] }

| verdict | meaning | |---|---| | verified | restored recently, and the restored row counts matched | | unverified | never restore-tested, or the last test is too old to be evidence | | suspect | size collapsed, or the restore "succeeded" with missing rows | | failed | the job failed, or a restore test failed |

A restore of an empty dump succeeds. So a passing restore test does not clear a size collapse — suspect survives it, and row counts are compared between backup and restore when both are available.

RPO, and the two hours it hides

Measured from the data cutoff, not job completion. A two-hour dump whose RPO is measured from when it finished reports a recovery point two hours fresher than it actually has. Nothing errors; the number is simply wrong in the optimistic direction. When no cutoff is recorded, the result is returned with rpoImprecise: true and a reason saying so, rather than a confident wrong number.

Retention that counts the right thing

  safeToDelete(assessments, { keepVerified: 1 });
  // { deletable: [], held: [{ id: "old", why: "…nothing proven to fall back on" }] }

It will not propose deleting anything if doing so leaves fewer than keepVerified verified copies — including refusing to delete unverified backups when no verified copy exists, which is the case where a date-based policy does the most damage.

What it does not do

| not included | why | |---|---| | Taking backups, or running restores | it judges the evidence your system already produces | | Talking to S3/RDS/pg | no transport, no credentials, no cloud SDK | | Deleting anything | safeToDelete returns a proposal. A tool that judges backups and also deletes them is one bug away from being the incident |

Thresholds (50% size drop, 30-day restore-test freshness, 1KB floor) are defaults and arguable. Every assessment carries reasons so the judgement can be checked rather than trusted.