Restore Testing: Turning a Green Job Into Evidence

A backup job that reports success proves the job ran. A restore test proves the data comes back. Here is how to run one that gives an auditor real evidence.

Written by İlker Pehlivan

The three things a test has to cover
Write down what failed

A restore test answers one question that no backup report can answer: if this system were gone right now, what would we get back and how long would it take? Everything else about a backup is preparation for that answer.

The backup job and the restore are two different systems that happen to share a file format. The job proves data was written. Only a restore proves the data was written in a form that comes back, that the encryption key still exists, that the agent version can still read it, and that someone in your team knows the procedure. That gap between a finished job and a real copy is the idea the whole backup and recovery guide is built on, and it is the one thing the 3-2-1 rule cannot check for you: the rule counts copies, only a restore proves one of them comes back.

The three things a test has to cover

Data completeness. Restore a system and look for what is missing rather than what is present. Missing datasets are the most common finding, because backup scope is set once and the environment keeps changing around it.

Time. Measure how long the restore actually took, including the parts nobody counts: locating media, provisioning target hardware, waiting for a download. This number is your real recovery time, and it is usually several times the estimate.

Procedure. Have someone other than the person who built the backup run the test, working from the written procedure. If they cannot, the procedure is not documentation, it is a reminder for one person.

Write down what failed

The value of a restore test is concentrated in what went wrong. A test that produces “restore successful” and nothing else has told you almost nothing, because the interesting information is in the friction: the step that was missing from the runbook, the license that had to be re-entered, the forty minutes spent finding out where the encryption key was stored.

Record those and fix them one at a time. That record is also the artifact to hand over when someone asks whether your recovery plan is real.

A plain text file next to the runbook is enough. What matters is that it is written during the test, not reconstructed afterwards:

Date        : 2026-03-14
Restored    : FS01, full system, to spare host
Source copy : offsite object storage (immutable tier)
Started     : 09:12   Usable: 11:48   Elapsed: 2h36m
Missing     : D:\archive excluded from job since 2025-11 (nobody noticed)
Friction    : encryption key not in runbook, 40 min to locate
Run by      : second engineer, working from written procedure only

The two lines that matter most here are the last two, and neither of them is a technical failure. One is a documentation gap and the other is a scope gap. Those are the findings a green backup report can never give you.

Questions about restore testing

Can automated verification replace a manual restore test?

It replaces part of it. Automated boot verification catches corrupt images and broken chains, which is most of the technical failures. It does not catch a missing dataset that nobody included in the job, and it does not tell you how long a real recovery takes with your team.

What should a restore test produce?

A short record with the date, what was restored, where it was restored to, how long it took, and what went wrong. The failures are the valuable part; a test that records only successes is a formality.

Written by

İlker Pehlivan

Network and systems engineer, founder of Serçe Bilişim

I run the networks and servers that other people's work depends on. Before founding my own consultancy I administered the backbone network, firewalls and core systems of a large multi-site organisation with thousands of users. I write about the things that actually broke.

The 3-2-1 Backup Rule, and Where It Stops Being Enough

Three copies, two media types, one offsite. What each number is actually protecting you from, and why ransomware forced most teams to add a fourth condition.

On this page

Part of this guide

Backup and Recovery