How to prove that a backup can be restored
By Lucas Flores, IT Systeme Flores UG. Last updated
You prove that a backup can be restored by restoring from it: regularly, on a schedule you keep, and by comparing the result with what was recorded when the backup was made. In practice that is a restore test, a read-back of a sample of the data, a hash comparison against the recorded checksums, a fixed rhythm such as weekly, and written results. A finished backup job says only that data was written. Restow runs this check every week and shows the result as recovery readiness.
Why does a successful backup job prove nothing?
Because "completed" means the write worked, not that the data can be read again. An encryption key can drift out of step with what wrote a chunk, storage can damage a block that is not read for months, and a format change can quietly break compatibility with older backups. None of that shows in the job's own status. It shows when somebody tries a restore, which is the worst moment to find out.
What counts as proof?
Five parts, and the proof is only as good as the weakest one:
| Part | What you do | What it shows |
|---|---|---|
| Restore test | Restore real data into a separate target, never over production. | The restore path works end to end, including keys and permissions. |
| Sample read-back | Draw items at random from the newest backup and read them back through the same path a real restore uses. | The backup is readable and decrypts, for data you did not choose in advance. |
| Hash comparison | Compare a checksum such as SHA-256 of what came back with the one recorded when the backup was made. | What came back is byte for byte what went in, not merely something that opens. |
| A regular rhythm | Repeat it on a fixed schedule, for example every week, and after changes to the setup. | It still works today. A single test proves only the day it ran. |
| Documented results | Write down date, backup, sample, method and outcome, and keep it. | You can show it to a colleague, a customer or an auditor, and see a trend. |
How can you do it without special tools?
Any backup product can be checked by hand with a short routine. On a Linux server, for example: record checksums of a random sample of files with sha256sum (relative paths) before the backup, restore those files into an empty folder, and run sha256sum -c on the list there. Every line must say OK. For mail, restore a sample of messages into a test mailbox and compare them with the originals, then do a whole-mailbox restore into a test mailbox from time to time. Write the result down. Do it on a schedule, not when you remember.
How often should you test?
The sample read-back at least weekly, because that is how quickly a silent problem should be found, and a full restore drill into a test target every quarter and after any change to storage, keys or the backup tool. That is our suggestion, not a rule from a standard; your own risk and your customers' contracts may ask for more.
How does Restow do it?
When Restow makes a backup it records a SHA-256 checksum of every item. Every week, for every mailbox, OneDrive and IMAP account, a restore check draws 20 mails, 20 files and a few calendar entries and contacts from the newest backup at random, reads them back through the restore path including decryption, and compares what comes back with the recorded checksums. For servers and clients, the agent also restores a few files into a temporary folder on the machine, compares them there and deletes the copy. The result is shown as recovery readiness: Ready (green) only after a check of the newest backup passed, and "Unverified" for a backup that exists but has not been checked, never green by default. A report per check lists what was read back, and alerts can send a mail, a bell entry or a signed webhook when a check fails.
Since 0.4.0 two more checks exist. A file share is checked after every new restore point: up to 20 sampled files are read back and compared, and the repository gets a weekly restic check of 5 percent of its data. SharePoint sites are checked like OneDrives, by sampling library files. For Proxmox VE (a preview), a job can also run boot tests, off by default: a restore point is restored as a new guest cut off from the network, started, checked for an answer from the QEMU guest agent and deleted again. A green boot test means the guest answered, not that every application inside works; Windows guests without the guest agent can reach yellow at best. Since 0.4.2 every new restore point of a Proxmox VE guest is also read back within minutes of its backup: a sample of its blocks is compared with the recorded checksum.
Next to that, a storage check reads packs again and compares them with their recorded size and checksum: a sample every week and every pack every month. Since 0.4.2 it tells a pack it could not read for the moment (a connection or permission error) from a damaged one: such a pack is read again and rated Attention rather than Not restorable, unless it stays unreadable in three checks in a row over at least 24 hours. And the audit log records every read and restore, so the history of who restored what is itself evidence. The details are on how Restow proves that your backups can be restored, in the verification feature page and in the documentation.
What are the limits of a sample?
A sample is a sample: 20 mails out of 50,000 prove that the restore path and those mails work, not every single mail. The monthly storage check, which reads every stored pack, closes much of that gap. The weekly check does not restore into a live Microsoft 365 mailbox; a full test restore into a separate target is planned and is not built, so restore a test mailbox yourself from time to time. And Microsoft 365 backup and restore have not yet run against a real tenant in Restow's release checks; they are covered by tests against a simulated Graph API. That is why Restow, still a beta, should run beside an existing backup until you have verified restores against your own data.
Frequently asked
Is a restore test the same as verifying the stored data?
No, they answer different questions. Verifying the stored data (reading packs and comparing checksums) shows that the storage still holds what was written. A restore test goes through the same path as a real restore, including decryption and reassembly, and compares the result with the original. You want both: the first finds silent damage early, the second shows that the whole chain works.
How many items should I sample?
There is no magic number. Cover every kind of data you protect (mail, calendar, files, a database dump), draw the items at random so that you do not always test the same easy ones, and make the sample big enough that a failure would show. Restow draws 20 mails, 20 files and a few calendar entries and contacts per mailbox, and up to 20 files per machine; a manual routine can be much smaller if you repeat it.
Do I have to restore into production to test?
No, and you should not. Restore into a separate target: an empty folder, a test mailbox, a scratch VM. A restore that overwrites live data is a risk, not a test. Restow's restore is non-destructive by default and its weekly check reads the backup on the server without writing into a mailbox or over a machine's files.
What should the written result contain?
The date, which backup was tested (job and restore point), what was sampled and how many items, the method, the outcome per item or in total, the person or system that ran it, and what was done about any failure. One line per run is enough if it is always the same line, kept where an auditor or a colleague can find it.
Does Restow prove everything about a backup?
No. The weekly check proves that a random sample reads back intact through the restore path; it does not restore into a live Microsoft 365 mailbox, and a full test restore into a separate target is planned, not built. Restow also says what its release checks have not covered yet, for example Microsoft 365 backup and restore against a real tenant.
Why restore tests matter more than backups · EWS retirement: what backup tools need now
Read more in Learn: the 3-2-1 backup rule and the "0" in 3-2-1-1-0 →