Why restore tests matter more than backups
By Lucas Flores, IT Systeme Flores UG. Last updated
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
- UnverifiedNot 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 that was never read back and verified 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: it reads a sample back through the restore path and compares it with the recorded hashes, with any failure surfaced on that mailbox's own status. It does not restore into a Microsoft 365 mailbox or OneDrive; the optional test restore into a target is not wired up in 0.2.1. File shares are checked after every new restore point, and Proxmox VE (preview) can boot-test restore points; neither is a full test restore into a separate target, which is planned. Full, per-item 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.
For 0.1.0 that checklist has stated gaps. Microsoft 365 backup and restore have not yet been run against a real Microsoft 365 tenant; they are covered by tests against a simulated Graph API. The endpoint agent's install script was run only in a Linux container, and the macOS installer was not part of the checks. In the final release run of 2026-10-01, 9 of 11 checks passed in full for the full build, one passed partly (the upgrade path cannot be checked yet, because there is no earlier release) and the Microsoft 365 check was skipped for lack of a Microsoft 365 tenant. The Community build passed 7 in full and one partly, and skipped the Microsoft 365 check and, by design, the journal and storage target checks, which run in the full build.
A method that works with any backup tool, from restore test to hash comparison to written results, is in how to prove that a backup can be restored.
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. It reads a sample back through the restore path and compares it with the recorded hashes, shown honestly as a sample. It does not restore into a Microsoft 365 mailbox or OneDrive; the optional test restore into a target is not wired up in 0.2.1. Since 0.4.0 file shares are also checked after every new restore point (up to 20 sampled files are read back and compared, plus a weekly restic check of 5 percent of the repository), and Proxmox VE (preview) can boot-test restore points: the restore point is restored as a new guest cut off from the network, started, checked for an answer from the guest agent and deleted again. Planned: a full test restore into a separate target for everything and complete-coverage verification of every backed-up item rather than sampling. Known gap in 0.2.1: Microsoft 365 backup and restore have not yet been run against a real Microsoft 365 tenant in the release checks; they are covered by tests against a simulated Graph API. See the features page on verification for the current, exact status.
Read more in Learn: the 3-2-1 backup rule and the "0" in 3-2-1-1-0 →