How to document a backup restore test

The failure mode: a screenshot instead of a restore

One person recounts an MSP that tried to pass off something short of an actual test: "I know of one MSP who tried to convince me that their backup device having a 'screenshot' of each VM after it was backed up was proof that it could be restored to working order" (r/sysadmin). A screenshot of a VM taken at backup time proves the backup process ran; it proves nothing about whether that image will actually boot and serve data when it is needed. The same discussion notes the more common version of this gap: "auditor sees 'backup policy: exists, configured, retained 30 days' and marks it green. nobody asks 'when did you last run a restore drill?'"

A separate thread on cyber-insurance claims being denied puts the underlying question plainly: "Backups were configured, but was the restore tested on schedule?" (r/msp). Configuration is not a test. Only an actual restore is.

What the record needs

A restore test that will hold up as evidence records five things, every time it runs:

• What was restored — a specific system or dataset, named, not "a backup" in general.
• From which restore point — the date and time of the backup that was restored, so the age of the tested data is on record.
• The result — restored successfully, restored with issues (name them), or failed.
• A timestamped screenshot — of the restored system actually running or the data actually accessible, not of the backup job's completion status.
• Who ran the test — named, not "IT."

A one-page template

Run the same five fields on a fixed cadence — quarterly is the common default — and keep every past test rather than overwriting the last one. One row per test, in a table anyone can scan:

A failed or partial test belongs on the record too. An unbroken log of clean results with no failures ever recorded reads, to a skeptical auditor, like a log that only gets filled in after the fact.

The same fields as a recurring control

Once this is running on a schedule, it is a control like any other: it has an owner, a frequency, and evidence attached to each run. Treating it that way — rather than as a one-off exercise you did once for an audit — is what lets you answer "when did you last run a restore drill" with a date instead of a guess.

Which systems get a restore test, and how often

Not every system needs the same frequency. A production database or the system running client-facing work deserves a quarterly restore test at minimum; something rarely touched and easily rebuilt from source can reasonably go longer between tests. What matters is that the frequency for each system is decided in advance and written down, rather than tests happening whenever someone remembers, because "whenever someone remembers" is indistinguishable, on paper, from never.

Recording a partial or failed test

A restore that comes back with issues — a slow restore, a file that did not open, a service that needed a manual restart — is not a failure of the documentation process; it is the documentation process working. Note exactly what went wrong and what was done about it. A record with an occasional honest "issues" entry, followed by a note on the fix, is more convincing to a skeptical reader than a perfect column of "success" that never once shows the test finding anything.

Where to keep the record

Store the log somewhere separate from the backup system itself. If the backup platform is ever the thing that fails, a log kept only inside it fails along with it. A shared, dated file or a dedicated control record works; a folder on one engineer's laptop does not, for the same reason a single copy of a backup is not really a backup. The same applies to the timestamped screenshot from each test: keep it alongside the log entry it belongs to, not scattered across whichever machine happened to run that particular test.

Questions

How often should a restore test run?

Quarterly is a reasonable default for most systems; anything a carrier or client explicitly asks about should match the frequency they expect, stated in writing.

Does a successful backup job count as a restore test?

No. A job completing without error is a necessary condition, not evidence that the data restores. Only an actual restore, checked against the five fields above, counts.

Is a screenshot of the backup software enough evidence?

Only if it shows the restored system running, not the backup job's completion status. The distinction is the entire point of the test.

Next step

ControlLedger turns this template into a recurring control per client: it schedules the test, holds the five fields and the screenshot as attached evidence, and includes every past run — passed or failed — in the Evidence Pack.