A backup job reporting success proves a file was written. It does not prove the file can be read, is uncorrupted, or contains what you think. This log records the only thing that answers that question: an actual restore, timed and verified.
What you get
One row per restore test, with the time taken measured against your RTO
A verification column that demands evidence, not a tick
A failure log, because failed restores are the entire point of testing
A coverage view showing which systems have never been restored
How to use this template
1
Restore to somewhere other than production. Restore into an isolated environment. A test that overwrites live data is a test you will only run once, and a restore target on the same storage as the original proves nothing about a storage failure.
2
Time it and compare against the RTO. The number that matters is wall-clock time from decision to service usable. Most teams discover their real restore time is several times their stated RTO, and the gap is far more useful than a pass/fail.
3
Verify the content, with completion as the weaker signal. Open the restored database and run a row count. Open the restored file share and check a known document. 'Restore completed' is the claim; the verification column is the evidence.
4
Log the failures in detail. A successful test tells you little. A failed one tells you the retention was too short, the encryption key was not backed up, or the agent stopped reporting in March. Record the cause and the fix.
What's inside
Here's a preview. Unlock the free download to get all 5 sections (4 more below).
Restore test log
One row per test. The verification column should describe what you checked, not say 'yes'.
Date
System restored
Backup date used
Restore target
Time taken
RTO
Met RTO
Verification performed
Result
Tested by
2026-09-18
fin-db-02 (PostgreSQL)
2026-09-17 02:00
Isolated recovery VPC
2h 41m
4h
Yes
Row count on 6 key tables matched source; app connected and loaded dashboard
Most backup policies describe a schedule and stop. The clauses that decide whether you recover from ransomware are the ones usually missing: an immutable copy, an offline or logically-separated copy, and a stated obligation to test restores.
RTO and RPO are usually set by asking the business what it wants, which reliably returns 'zero'. This worksheet sets them the other way round: measure what you can currently deliver, price the gap, and let the business choose knowingly.
Most DR plans are written to satisfy an auditor and are unusable in an actual disaster: too long, structured by system rather than by sequence, and assuming the authors are available. This one is ordered the way the event unfolds.
Tier 1 systems quarterly at minimum, with a full application-level restore at least annually. Lower tiers can go annually. The cadence matters less than the coverage: a system never restored has an unproven backup regardless of how often the job runs.
What counts as verifying a restore?
+
A check specific to the system: row counts matched against source for a database, opening known documents on a file share, logging into the application and completing a transaction. 'Restore job completed' is the claim being tested, so it cannot also be the evidence.
Should restores be tested in production?
+
No. Restore into an isolated environment so a failed or partial restore cannot damage live data. A target on the same storage as the source also proves nothing about a storage-level failure, which is one of the scenarios you are testing for.
