Why restore tests matter more than backups
A backup that has never been restored is a claim, not a fact. The only way to actually know a backup works is to read it back and check. A green "backup completed" status proves the write succeeded, nothing about whether the data comes back correctly later, which is the only reason the backup exists at all.
Back up
Mail, calendar, contacts and OneDrive, incremental and encrypted, on your storage.
Pick a sample
Every week, per mailbox and OneDrive: about 20 mails, 20 files, calendar and contacts.
Read it back
From the latest backup, through the same path a real restore uses.
Compare
Byte for byte against the recorded checksums. Only a match counts.
Shown per mailbox as recovery readiness
- ReadyLatest check passed
- AttentionWarnings in the check
- Not restorableCheck failed
- Not provenNot read back yet
What tends to go wrong, silently
Encryption keys drift out of sync with what was used to write a chunk. Storage silently corrupts a block that isn't read again for months. A format change quietly breaks compatibility with older archives. None of these show up in a backup job's own success status. They only show up when someone actually tries to restore, which is precisely the moment nobody wants to discover a problem for the first time.
What a green "backup completed" does not tell you
The job status proves the write. Only reading back proves the restore.
| Silent failure | Shown by the backup job? | Shown by a restore test? | Caught at |
|---|---|---|---|
| Encryption key out of sync with what wrote a chunk | No | Yes | Decrypt |
| Storage silently corrupts a block nobody reads | No | Yes | Read back, compare |
| A format change breaks older backups | No | Yes | Read back |
What Restow does about it
A backup without a verified restore is shown, in the product, as not done, not quietly rounded up to success. Today that's enforced by a weekly sampled recovery-readiness check per mailbox and OneDrive: an actual restore of a sample, compared back, with any failure surfaced on that mailbox's own status. Full, per-item restore verification for everything backed up (not a sample) is in active development; see the verification feature page for exact current status, and how Restow is built for the release checklist every version has to pass, which already includes a full backup-and-restore run with a byte-for-byte hash comparison before any tag ships, plus proving a restore works from the standalone tool with no Restow server running at all.
Frequently asked
Why is an untested backup not actually a backup?
Because "backup completed successfully" only proves the write succeeded. It says nothing about whether the data can actually be read back correctly later, which is the entire point of having a backup in the first place. A corrupted chunk, a broken encryption key, or a subtle format bug can all sit silently inside a backup that reports green for months, discovered only at the worst possible moment: during an actual emergency restore.
What does Restow check today, versus what's still coming?
Today: a weekly sampled recovery-readiness check per mailbox and OneDrive, an actual restore of a sample, compared back, shown honestly as a sample. In development: full, complete-coverage verification of every backed-up item, restoring into a separate target automatically rather than sampling. See the features page on verification for the current, exact status.