Proving backups actually restore
A backup that has never been read back through a restore is a theory, not a guarantee. Restow treats "backed up" and "proven restorable" as two different, separately-shown states, and a backup without a verified restore is shown as not done, not as a quieter shade of success.
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's checked today
A weekly sampled recovery-readiness check runs per mailbox and OneDrive: Restow actually restores a sample and compares it back, then shows the result plainly as a sample-based check, not as complete coverage it hasn't earned. Where a check fails, that failure shows up in the mailbox or OneDrive's own status: it does not get averaged away into an overall green dashboard.
Servers and clients are covered too
For a server or client backed up with the agent (see server and client backup), the check runs after every new good backup. The agent records the SHA-256 of up to 20 random files, the Restow server reads them back from the repository and compares the hashes, and the result is green only when they match. On top of that the repository is checked once a week. Both results feed Recovery Readiness, so a machine counts as recoverable only after files were actually read back with matching hashes. A failed check says what happened, why and what to do: see the failure explanations in the documentation.
What's in development
Full test restore into a separate target, and verifying every backed-up item rather than a weekly sample, is actively being built. Until it ships, the sampled check is the honestly-labelled interim state. See the roadmap for exact status, and how Restow is built for the automated release smoke run that gates every release, including an IMAP backup and restore with a byte-for-byte comparison and a restore with the server stopped.
Frequently asked
How does Restow verify that a backup can actually be restored?
By restoring it and checking, not by assuming a successful backup job means the data is recoverable. Today that runs as a weekly sampled recovery-readiness check per mailbox and OneDrive, shown as a sample rather than a full guarantee. Full, complete-coverage restore verification for every backed-up item, restoring into a separate target automatically, is in development. See the roadmap.
What happens if a verification check fails?
It's shown, not hidden. The affected mailbox or OneDrive's recovery-readiness status reflects the failure immediately, the same honesty rule that applies to Graph throttling waits and every other known limit in the product. A failed check also says what happened, why, and what to do, with the technical details kept for a support case.
Is an unverified backup shown as successful?
No. A backup that hasn't been confirmed by an actual restore is treated, and displayed, as not proven, never quietly rounded up to "done."
Are servers and laptops verified too?
Yes. After every new good backup of a server or client, the agent records the SHA-256 of up to 20 random files. The Restow server then reads those files back from the repository and compares the hashes, and the check is green only when they all match. The repository itself is also checked once a week. Both results feed Recovery Readiness.