Your backup is green. So what?

Every morning your backup tool sends the same report: job completed successfully. Green light, case closed, coffee.

The problem is that the green light answers the wrong question. It says "the copy was written." It does not say "this copy can be restored and used." And the gap between the two is enormous.

The numbers: the gap between backup and restore

The industry data is brutal. According to Backblaze's State of the Backup 2024 survey (300 IT decision-makers polled in the United States), only 57% of enterprise backup jobs complete successfully. More worrying still: only 61% of restore attempts deliver the expected result. In other words, roughly 4 restores out of 10 fail at the exact moment the data is needed.

And that moment comes around more often than people think: close to 39% of organisations restore data from their backups at least once a month.

On the threat side, recent ransomware reports converge: the vast majority of attacks now target backup repositories directly, and a large share of those attempts succeed. Organisations whose backups were compromised face recovery costs several times higher than those whose backups stayed intact.

Why a "successful" backup fails at restore time

A green job can hide a dozen silent failures:

• Corrupt or truncated dump: the file exists, but pg_restore stops at 80%.
• Incomplete archive: the backup has been excluding a critical directory since a config change six months ago. Nobody noticed.
• Missing dependencies: the SQL dump references an extension or a role that only exists on the source server.
• Stale credentials: the S3 bucket access key was rotated; the job still writes, but nobody can read any more.
• Encrypted backup… with a lost key: technically perfect, practically useless.
• Missed window: the job "succeeds," but after the intended window — your real RPO isn't the one you think it is.

None of these raise an alert. All of them are discovered on incident day.

The only valid proof: actually restore

Every SRE knows the answer: test restores regularly. The problem was never the "what," it's the "how":

1. It's manual and time-consuming. Provision an environment, download the archive, restore, verify, clean up, document. Nobody does that every week.
2. It's rarely documented. When a test does happen, the evidence lives in a Slack message or in the memory of the engineer who ran it.
3. The tools that automate it are enterprise-grade. Veeam SureBackup, Commvault, Rubrik: powerful, but tied to their own backup ecosystem, and out of budget for an SMB or a DevOps team backing up with pg_dump + S3.

What RestoreProof does

RestoreProof automates the restore test and produces cryptographic proof of it, without your data ever leaving your infrastructure:

• A runner deployed on your side (binary, Docker, Helm or systemd) fetches the backup from its source (S3 or compatible, HTTP, local), restores it inside an ephemeral container, and runs validation probes: archive integrity, canary files, PostgreSQL/MySQL queries, HTTP endpoint.
• The runner signs the verdict with Ed25519, using a private key that never leaves your infrastructure. The report is tamper-proof.
• The SaaS control plane only ever receives the signed verdict — never the data, never the secrets.
• Tests are scheduled with cron: nightly, weekly, at your own pace. You get a history of timestamped evidence you can hand to an auditor (NIS2, ISO 27001, cyber insurance).

That's the difference between "our backup ran" and "here is the signed proof that our March 14 backup restores and contains the expected data."

FAQ

What is the difference between verifying a backup and testing a restore? Verifying a backup (checksum, size, file presence) confirms that the copy exists and hasn't been altered. Testing a restore confirms that you can rebuild a usable system from that copy: database started, data present, application working. Only the second proves recoverability.

How often should restores be tested? Standards (ISO 27001 A.8.13, ENISA/NCSC guidance) call for "regular" testing, and auditors generally expect evidence less than 6 to 12 months old. In practice, with automated testing, nothing stops you from running a daily test on critical backups.

Can you test a restore without exposing your data? Yes, if the test runs inside the infrastructure that already holds the data. That's the RestoreProof model: restore and validation run on your side, and only the signed verdict is sent to the SaaS.

Sources to link: Backblaze State of the Backup Survey 2024; ISO/IEC 27001:2022 Annex A 8.13; Directive (EU) 2022/2555 (NIS2), Article 21.