How to Test That Your Backups Actually Restore

A successful backup job shows only that the backup software finished its task. It does not prove that you can retrieve or read the data, or use it to bring a service back online. To verify recovery, restore a backup using the steps you would follow during an outage. Then check the data and service in a safe test environment.

A restore test should show that you can access the right backup, recover usable data, and meet the workload's limits for recovery time and data loss. The sections below explain how to test those outcomes without overwriting live data, and how to use the results to improve recovery.

Decide what a successful restore means

Choose a workload and a failure scenario before you start. A test might recover a deleted file or database, or restore a full service in a separate recovery location. A full-service restore exercises more of the recovery path because it requires infrastructure and dependencies, along with operator access.

Write down which checks will count as success. For a file restore, you might confirm that the expected files exist, open correctly, and match known checksums. A checksum is a calculated value used to detect whether file contents changed. For a database, check that expected records appear and run a database integrity check. For a service, start it and test a representative user action, such as running a report or completing a test transaction. AWS recommends setting validation criteria before a restore test.

A backup-integrity check and an operational restore answer different questions. An integrity check can help detect damaged backup data; a restore test shows whether you can recover and use it. NIST guidance supports testing selected backup information, while AWS advises checking that restored data can actually be queried or retrieved.

Restore into a separate environment

Restore to a new or nonproduction location so the test cannot overwrite live data or disrupt users. Use the backup copy and recovery route you would rely on during the failure you are testing. If your recovery plan depends on a separate account or region, test that route. If it depends on an offline copy, test that route too. A restore from an easy-to-reach local copy does not verify a more isolated copy.

Follow the recovery instructions operators would use during an outage. Those instructions are often called a runbook: a written sequence of recovery actions. Record obstacles such as missing permissions or unavailable encryption keys. Also note unclear instructions and dependencies the runbook leaves out. These problems can block recovery even when the backup itself is intact. AWS recommends using the established recovery procedure, and Microsoft recommends testing operator access and recovery instructions.

For a ransomware recovery test, use a clean, isolated environment and check the restored workload before reconnecting it to production. Isolation helps prevent the test from contacting compromised systems or relying on compromised credentials. CISA recommends maintaining offline backups and testing recovery; Microsoft also advises validating a recovery in a clean environment before returning the workload to service.

Validate the data and the service

Check the recovery in stages. First, confirm that you can find and access the chosen backup, including any credentials or decryption keys needed to use it. Then check the restored data against your success criteria. Verify expected files or records and compare counts or sizes. Run checksums or data-specific integrity checks where they apply.

Next, test the restored data through the service that uses it. Open files, query the database, run a report, or complete a representative transaction. If the critical service relies on other components, restore and test those dependencies as well. A database that passes an integrity check does not by itself prove that users can complete the business task that depends on it.

A backup product’s automated restore test can make routine recovery checks easier, but its result covers only the resources and checks that product supports. You still need to verify the functions and dependencies that make your workload usable. For example, AWS Backup documents resource-specific limits for automated restore testing.

Measure recovery time and data loss

Set recovery targets for each workload. The recovery time objective (RTO) is the longest acceptable time to restore service. The recovery point objective (RPO) is the maximum acceptable amount of data loss, commonly expressed as a period of time.

Start the clock at a consistent point, such as when you begin recovery, and stop when validation shows that the service is ready to use. Include the time needed to restore dependencies and complete checks. A restore job that finishes quickly still misses the RTO if the service remains unusable afterward. To assess the RPO, compare the recovered data with the time of the failure. A backup can restore correctly and still be too old to meet the workload’s data-loss limit.

Record which backup and recovery location you used. Note what passed or failed and how long recovery took. Also record the evidence showing the age and usability of the recovered data. AWS guidance recommends measuring recovery through validation and comparing the result with RTO and RPO. If the test misses a target, identify whether the cause was the backup, recovery access, a dependency, the instructions, or the target itself, then assign a corrective action.

Set a testing cadence that fits the workload

No single test interval fits every workload. Set the cadence based on how critical the service is and how often its data or infrastructure changes. Also weigh the risk and effort involved in a test. Test again when backup settings or data structure change. Retest after changes to infrastructure or recovery instructions. Microsoft recommends adjusting restore-test frequency to the rate of those changes, while NIST leaves exercise frequency to the organization.

Use smaller tests to check specific files or resources, and periodically test a broader recovery path when the workload’s risk justifies it. A sample restore provides evidence about the items and path tested; it does not prove that every backup type or dependency will recover. Expand the test when a workload has high impact or when a smaller test leaves important recovery steps unverified.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com