A backup nobody has restored is a hope

Every backup system tells you it worked. It has to — it finished writing without an error, so from its point of view it did.

What it cannot tell you is whether the data comes back. That is a separate question, and it has an unpleasant property: you will ask it for the first time on the day you can least afford the answer to be no.

The ways a "successful" backup fails

• The database was written mid-transaction and the dump is inconsistent.
• Everything was captured except the one directory added six months ago.
• The archive is encrypted with a key that lives only on the machine that died.
• It restores perfectly, and takes eleven hours, and your commitment was four.
• The job stopped running in March and the alert for it was silenced in February.

None of these show up in a backup report. All of them show up in a restore.

Restore drills

So we restore them on a schedule, whether or not anyone asked. Not a checksum, not a "verify" flag — an actual restore, performed, with the result recorded.

That produces a number: how many restores were replayed in the last fourteen days, and how many worked. On our own hosting that figure is published on the product page, because a number is falsifiable and "enterprise-grade backups" is not.

Why the number matters more than the policy

Two providers can have identical backup policies. Daily snapshots, fourteen days retention, off-site copies. Written down, they look the same.

One of them restores them regularly. The other has never tried.

You cannot tell those apart from a feature list, which is precisely why the feature list is not the right place to look. Ask the question that has a date for an answer: when did you last restore one, and did it work?

What to do with your own

You do not need a platform for this. You need a calendar entry.

1. Pick a real backup, not a test one.
2. Restore it somewhere that is not production.
3. Time it, and write the time down.
4. Check the data, not just that the process exited zero.
5. Do it again next month.

The first one will find something. They always do — and finding it on a Tuesday afternoon is the entire point.

If the calendar entry is the part that never happens

None of this needs a provider — the drill is a calendar entry and a machine that is not production. If you would rather it were somebody else's calendar entry, backups on our own hosting are daily, kept fourteen days, restored by you from a button rather than a support ticket, and replayed on a schedule so that the question above has a date for an answer.