The reliable way to know how long a restore takes is to run one and time it. Break the run into stages, record each, and add the time to validate and reconnect the application. Compare the total to your recovery time objective and fix the slowest stage first.
Why estimates miss
Teams often estimate restore time from backup size and disk speed. That leaves out most of the work. NIST SP 800-34 defines the recovery time objective as the maximum time a system resource can remain unavailable before there is an unacceptable impact, and notes that time to reprocess data after an outage adds to it. A restore that copies data quickly but then needs hours of validation misses the objective just as much as a slow copy does.
The stages to time
| Stage | What to record | Common surprise |
|---|---|---|
| Decide and declare | Time from failure to a decision to restore | Waiting for someone with authority |
| Gain access | Time to reach backups and credentials | Keys or vault access that is itself down |
| Provision | Time to create the target environment | Quotas, approvals, or missing templates |
| Transfer | Time to move data to the target | Slower network than expected |
| Restore | Time for the database or system to load it | Index rebuilds, log replay |
| Validate | Time to confirm data is correct and complete | No agreed checks |
| Reconnect | Time to point applications and users at it | DNS caches, configuration, cold caches |
How to run the test
- Choose a system and a recovery target. Write down the number you hope to meet.
- Pick a recent backup, not a handpicked one. Use the same procedure you would use in a real event, with the same people on call.
- Start a clock and record the time at each stage boundary.
- Restore into an isolated environment, never over production.
- Run your validation checks. If you have none, write three: a row count comparison, a spot check of recent records, and a login test.
- Write down what blocked you, what you had to look up, and what you guessed.
- Compare the total to the target and decide what to change.
What to change
- If access was slow, store recovery credentials where more than one person can reach them, and test them. See our post on break-glass credentials.
- If provisioning was slow, keep infrastructure as code for the target environment and test it.
- If transfer was slow, consider keeping a recent copy closer to where you would restore, subject to your protection requirements.
- If validation was slow, automate the checks.
- If the whole run is too long for the target, either change the architecture or change the target with the owner's agreement and record it.
Keep the evidence
Record the date, the system, the backup used, the times, and the result. It becomes proof for customers and auditors who ask whether you test recovery, and a baseline for later runs. Our post on backup and restore test evidence shows what to keep, without implying any report or certification.
When to repeat
Repeat after significant changes to the system, such as a new database version or a new storage location, and on a schedule. Quarterly is common for top services. A restore that worked a year ago says little about today.
A worked example: a database restore drill
This example is hypothetical. A team restores its main database from the latest nightly backup into an isolated environment and records what happens.
| Stage | Planned | Actual | Notes |
|---|---|---|---|
| Decide and declare | 10 min | 25 min | Waited for approval from a manager who was in a meeting |
| Gain access to backup | 5 min | 40 min | A single person had the decryption key, and was away |
| Provision target | 15 min | 20 min | Template worked after one quota request |
| Transfer | 30 min | 55 min | Backup stored in a distant region |
| Restore and replay logs | 60 min | 95 min | Index rebuild took longer than expected |
| Validate | 15 min | 30 min | Checks written on the spot |
| Reconnect application | 15 min | 35 min | Configuration change and a cold cache |
| Total | 150 min | 300 min | Target was 180 minutes |
The total is double the plan and well beyond the target. The most useful findings are not the slow copy. They are the approval delay and the key held by one person, which together cost over an hour. Neither would have shown up in an estimate based on data size.
Step by step: fixing what the drill found
- Fix decision rights. Write who can declare a restore and name a backup, as in our post on pre-authorized decisions.
- Fix key access. Give at least two people access to the recovery key, store it safely and test retrieval. Our post on backup encryption keys explains the risk of a lost key.
- Fix transfer. Keep a recent copy in the region where you would restore, within your protection requirements.
- Fix validation. Turn the checks written on the spot into a script and store it with the runbook.
- Fix reconnect. Prepare the configuration change in advance and add a warm up step.
- Rerun the drill after the changes and compare the stages.
Record the evidence in a shareable form
| Field | Example entry |
|---|---|
| System | Main database |
| Date and time | Drill date and start time |
| Backup used | Identifier and age |
| People involved | Names or roles |
| Target | The agreed recovery time |
| Result | Actual total and per stage times |
| Issues | Approval delay, key access |
| Actions | Owner and due date for each |
This record serves two audiences. Engineers use it to improve the process. Customers or auditors who ask about recovery testing can be shown the substance without any claim beyond what you did.
Restore is more than one system
Real recovery often involves several systems restored in an order: identity, then data stores, then applications. Time the whole chain at least once a year, not just the pieces. Dependencies between systems often add more time than any single restore.
Ransomware and restore
If the reason for a restore is a compromise, restoring quickly is not enough. You must rebuild trusted systems and make sure the restored data is clean. Our post on the order of recovery after ransomware covers it. Time a clean rebuild as well as a plain restore.
Try it yourself
Open the framework mapping demo and look at how evidence is attached to a control. A restore drill record is the kind of evidence worth attaching to a recovery control.
Click through it at your own pace, or open it full screen.
Quick check
Does a successful backup job mean the restore will work?
No. A job that finished says the copy ran. A restore with validation shows the data is usable.
Can I test restore on production?
Avoid it. Restore into an isolated environment so a test cannot overwrite live data.
What should we do if the restore misses the target?
Record the gap, fix the slowest stage first and rerun. If the target cannot be met soon, discuss a revised target with the owner and document the decision.
Sources
Last reviewed: 19 October 2026.
