How to Test a Backup Restore Before You Need One

If you have never restored a backup, you do not know whether it works. A test gives you that answer on a quiet day, while there is time to fix what it finds.

CISA's #StopRansomware Guide tells organizations to keep offline, encrypted backups of critical data and to regularly test their availability and integrity. It explains why the offline part matters: many ransomware variants look for reachable backups and delete or encrypt them. The NIST Cybersecurity Framework 2.0 has the same idea as outcome PR.DS-11: backups of data are created, protected, maintained, and tested.

This guide walks through one restore test from start to finish.

1. List what you would need back

Write down the systems you could not run the business without. For a small software company, that list often includes:

• The production database
• File and object storage, such as buckets that hold customer uploads
• Code repositories and the infrastructure code that builds your cloud setup
• Secrets and configuration needed to run the app
• Company files and email in Google Workspace or Microsoft 365

Rank them. The top two or three are where your first test goes.

2. Set two targets with the business

Two numbers tell you whether a restore was good enough. Both come from NIST's contingency planning guide, SP 800-34 Rev. 1, and NIST's glossary defines them.

• Recovery time objective (RTO). How long a system can be in recovery before it hurts the business.
• Recovery point objective (RPO). The point in time you must be able to recover data to. In plain terms, how much recent data you can afford to lose.

These are business decisions. Ask the founder or the head of the product: "If the database were gone at 9 a.m., when must it be back, and how much of this morning's data can we lose?" Write the answers down. The test tells you whether you can meet them.

3. Check where the backups live

Before you restore anything, look at the backups themselves.

• Each system on your list has a backup, and you know where it is.
• Backups are encrypted.
• At least one copy is offline or in a separate account, so the same stolen admin login cannot delete both the system and its backups.
• You know who can delete backups, and that list is short.
• Backups run on a schedule, and someone gets told when one fails.

If any box stays empty, write it down. That is your first finding.

4. Restore into a safe place

Never test by restoring over production. Restore into a separate place, such as a new database instance, a test account, or a scratch folder.

Cloud services often support this. For example, Amazon RDS can restore a database to a point in time as a new instance without changing the source. AWS Backup can run scheduled restore tests and track how long each restore job takes.

Before you start, pick the moment you will treat as the failure, such as the time you begin the test. Then start a timer. Follow your written steps if you have them. If you do not, write the steps down as you go. Those written steps are what you will follow during a real outage.

Treat the restored copy like production data. Lock down who can reach it, and delete it when the test is done.

5. Check the data is right

A restore can finish and still leave you with bad data. NIST CSF 2.0 outcome RC.RP-03 says to verify the integrity of backups before you use them to restore.

• Compare row counts or file counts with the source.
• Find the newest record in the restored copy. The gap between that record and the moment you picked as the simulated failure is your real data loss window. Compare it with your RPO.
• Point a test copy of the app at the restored data and confirm it starts and a user can sign in.
• Spot-check a few records you know well.

6. Time it and write it down

Stop the timer when people could use the system again. That is usually later than the moment the restore job reports done. Compare that time with your RTO.

Record the test while it is fresh:

That record is the evidence a customer review or an auditor asks for when they ask whether you test your backups.

7. Fix the gaps and set the next date

Fix what the test found, then update your written steps. Put the next test on the calendar before you close this one.

CIS Control 11, Data Recovery, frames the goal as being able to restore systems to a pre-incident and trusted state. CIS Safeguard 11.5 says: "Test backup recovery quarterly, or more frequently, for a sampling of in-scope enterprise assets." CIS lists it for Implementation Groups 2 and 3. It sits outside IG1, the starting set. Our advice is the same: at least once a quarter for your top systems, more often for data that changes fast or that customers depend on, and again after any big change to how you store data. Rotate through the rest of your list over the year.

Where Grey Wing fits

In the Security Program we check backup protection and recovery procedures, and we help you practice your recovery plans with your team. If you want help, Let’s talk.

Sources

• CISA, #StopRansomware Guide: https://www.cisa.gov/stopransomware/ransomware-guide
• NIST Cybersecurity Framework 2.0 (PR.DS-11, RC.RP-03): https://www.nist.gov/cyberframework
• NIST glossary, Recovery Time Objective: https://csrc.nist.gov/glossary/term/recovery_time_objective
• NIST glossary, Recovery Point Objective: https://csrc.nist.gov/glossary/term/recovery_point_objective
• NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems: https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final
• Amazon RDS, Restoring a DB instance to a specified time: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html
• AWS Backup, Restore testing: https://docs.aws.amazon.com/aws-backup/latest/devguide/restore-testing.html
• CIS Controls, Control 11 Data Recovery: https://www.cisecurity.org/controls/data-recovery
• CIS Controls Assessment Specification, Safeguard 11.5 Test Data Recovery: https://cas8.docs.cisecurity.org/en/latest/source/Controls11/