Home  ›  Glossary  ›  Restore Testing

What is restore testing?

Restore testing is the routine recovery of backups into an isolated environment to confirm the data can be read, decrypted, started and checked within the recovery time objective. A successful backup job proves data was written; only a restore test shows that it comes back as a working system.

What does a job status leave unproven?

Backup software reports success when it has written the data, not when an application has started from it. Several failures stay hidden until a restore is attempted: a database copied mid-transaction, a missing credential or encryption key, a catalog that no longer matches the stored data, or a restore point that depends on an older one that has expired.

How does automated sandbox testing work?

Many backup products automate the test. The software mounts a restore point directly from the repository, boots it in an isolated network segment with no route to production, and runs scripted checks: the operating system responds, services start, the application answers a query, and a malware scan comes back clean. It records the result and timings, then removes the test machine. Booting from the repository uses the same mechanism as instant recovery, which is why such tests take minutes rather than hours.

Integrity validation runs alongside. The system rereads stored backup data and compares it with checksums recorded at backup time, which finds corrupted or missing blocks without a full restore. It proves the bytes are intact, not that the workload runs.

When does a restore test pass?

  • The workload starts, not only its files.
  • Its data is consistent: databases open, and recent transactions are present.
  • A malware scan of the restored system is clean.
  • The whole restore finished inside the recovery time objective.

A restore that works but takes nine hours against a four-hour objective is a failed test, and the failure is useful because it shows the gap before an incident does.

Which restore points and scale do tests cover?

There is no industry standard for frequency. Critical workloads are commonly tested more often than the wider estate, with a full rehearsal of a disaster scenario under disaster recovery testing. Two additions make tests closer to real incidents. Old restore points: recovery after an intrusion often reaches back weeks, to points no one has opened since they were written. Parallel restores: one machine says little about fifty restored together from the same repository, and restore throughput at that scale is the number the recovery plan depends on. Passed tests are the evidence behind the final zero in the 3-2-1-1-0 rule.

Frequently asked questions

Is verifying a backup the same as testing a restore?

No. Verification, such as checksums or a read-back, confirms the stored data is intact, while a restore test confirms the workload runs from it.

Do restore tests use production data?

Yes. They use real restore points, which contain production data, so the test environment needs the same access controls as production and no route back into it.

What does a failed restore test tell a team?

It shows a gap while there is still time to close it, such as a missing key, an expired dependency or a restore slower than the objective.