Restore Testing: Prove Your Backups Work

Published October 23, 2026 · Last reviewed October 23, 2026

Three levels of test

Match the effort to the risk. These frequencies are suggestions for a small business; adjust them with the owner.

• Monthly: file and mailbox-item restore. Recover a few files and one email from different dates. About thirty minutes.
• Quarterly: application or server restore. Recover the accounting data, the line-of-business database or a whole virtual machine into an isolated place and open it.
• Yearly: full rebuild exercise. Pretend the office is gone. Recover identity, the key systems and one user’s laptop from scratch, using only the documents in your recovery pack. Time the whole thing.

The monthly test, step by step

1. Pick a restore target that is not the original location: a spare laptop, a scratch virtual machine or an empty folder on a separate share.
2. Choose the item to restore without looking at which backup is easiest: one file from last week, one mailbox item from last month, and (quarterly) one whole application or server.
3. Start a timer, sign in to the backup console as the person who would do this in a real incident, and restore the item from the independent or immutable copy, not from the local cache.
4. Open the restored item and confirm it is complete. For files, compare checksums: run Get-FileHash in Windows PowerShell or shasum -a 256 in macOS Terminal on the original and the restored copy, and check that the values match.
5. Stop the timer. Write down the date, what you restored, where from, how long it took, who did it, and anything that surprised you.
6. Delete the test restore, fix every gap found, and put the next test in the calendar before you close the record.

What to improve when it goes wrong

Action

Put the test in the calendar with a named owner and a backup owner. Use a recurring entry in your shared calendar and a short record sheet kept outside the systems being tested.

Why it helps

Tests that depend on someone remembering stop happening within a few months.

Verification

The last three entries on the record sheet have dates roughly one month apart.

Fallback if delayed

If nobody has time, do the shortest test (one file from the off-site copy) rather than skipping the month.

Action

Test from the copy you would depend on in an incident, which is the immutable, offline or off-site one, using the credentials a responder would really have.

Why it helps

Local caches and fast recovery points can work while the copy that survives an attack has never been read.

Verification

The record sheet names the copy used, and it is the independent one at least every second test.

Fallback if delayed

If restoring from the off-site copy is slow, test one small item monthly and one large item quarterly.

Action

Scan restored data before reconnecting it. Restore into an isolated location and run your endpoint protection’s scan on it before it touches production.

Why it helps

A backup taken after an intruder arrived can carry their tools back into the network.

Verification

The scan log shows a completed scan of the restored folder with no detections, or the detections have been reviewed.

Fallback if delayed

Keep older restore points so you can choose one from before the problem started.

Common failure mode

Teams check the job status instead of restoring, restore onto the same machine where the original still exists, or restore only the easy items. The result is a record full of passes that would not survive a real incident. A second frequent error is never timing the restore, so the first time anyone learns it takes two days is during the outage. Use the restore-time tool to estimate and then compare with the timed result.

How it works

A restore test checks three things at once. Availability: the data is there and the copy is reachable. Integrity: what comes back is complete and unchanged, which a checksum comparison shows more reliably than opening a file and looking. Capability: the people, credentials, documentation and bandwidth you would have in an incident are enough to do the job in a useful time.

The third is the one most often missed, and it is why the test involves the person who would really do the restore. The recorded time feeds directly into the recovery-time plan.

Worked example

This is a hypothetical example with invented figures. An office manager runs the monthly test and restores a spreadsheet from the off-site copy. The restore works, but the record shows it took far longer than the nightly job suggested because the off-site copy sits behind a slow connection. The checksum of the restored file matches.

The test also reveals that the only person who knows the backup console login is away that week. The office manager writes the login location into the sealed recovery pack and names a second person. Neither finding would have appeared from the green status light.