Resources · 20

Test a backup restoration from copy to working service

Move from assumed backup availability to a rehearsed and documented recovery.

Updated 23 October 2026 · 7 min

What this guide helps achieve

Define useful recovery
Verify backup copies
Rehearse restoration
Close observed gaps

Quick check

Which service must return first, and what does it depend on?
Who can reach a copy during an outage?
Is the copy isolated and usable?
Does the restored service support a real journey?
What recovery time and data loss were observed?

Step-by-step method

01
Select a scenario
Start with a business service and map its data, identities, network and suppliers. Define the simulated failure and minimum usable result.
Deliverable: scenario brief and recovery order.
02
Set measurable criteria
Agree on an acceptable restore point, target time, functional checks and people who can validate the outcome. Separate a stated objective from an observed test result.
Deliverable: approved success criteria.
03
Check copies and access
Verify copy existence, date, integrity and isolation alongside the permissions needed to restore. Protect production data and secrets during the exercise.
Deliverable: copy inventory and prerequisites.
04
Restore safely
Follow the intended procedure with the intended operators, timestamp each step and record blockers. Use an isolated environment or a method that cannot overwrite the live service.
Deliverable: exercise log and rebuilt service.
05
Validate the service
Run a user journey and check data coherence, access and dependencies. Measure elapsed time and the gap between expected data and the restored point.
Deliverable: functional acceptance record and observed measures.
06
Fix and repeat
Assign gaps to owners, improve procedures or architecture and repeat failed steps. Update the continuity plan against the evidence.
Deliverable: action plan and next rehearsal date.

Acceptance case to reproduce

Fictional example: these inputs describe no customer or observed result.

View case inputs

{
    "date": "2026-10-12",
    "timezone": "UTC",
    "verified_data_through": "09:45",
    "backup_job_finished": "09:53",
    "disruption": "10:00",
    "file_restore_started": "10:10",
    "file_restore_finished": "10:42",
    "business_journey_validated": "11:05",
    "additional_log_replay": false,
    "target_rpo_minutes": 15,
    "target_rto_minutes": 60
}

Expected decision

The data criterion passes, but the duration criterion fails. Account for 10 minutes of waiting, 32 minutes of restoration and 23 minutes of validation, address blockers and replay the journey.

Restored files or a working service?

Fictional exercise on 12 October 2026; all times UTC. The backup job finishes at 09:53, but verified data ends at 09:45. Disruption starts at 10:00, file restoration runs from 10:10 to 10:42, and the business journey is validated at 11:05. No additional log is replayed. Exercise targets: 15-minute RPO and 60-minute RTO, measured here from disruption to validated journey.

Measure	Calculation	Interpretation
Unrecovered data window	10:00 − 09:45 = 15 min	15 minutes: the RPO target is met in this scenario. Counting from backup-job completion would incorrectly give 7 minutes. This duration does not establish how many records were actually lost.
File restoration	10:42 − 10:10 = 32 min	32 minutes for this technical step. It excludes 10 minutes before starting and 23 minutes of validation; it is not service recovery time.
Usable recovery	11:05 − 10:00 = 65 min	65 minutes, exceeding the 60-minute RTO by 5 minutes. A successful copy and a met RPO do not make the whole exercise successful.

NIST — SP 800-34 Rev. 1, Contingency Planning (2010)

Understand · try · decide

Recovery: separate restoration time from data age

RTO sets a recovery-time objective; RPO identifies the earlier point to which data must be recoverable. These objectives answer different questions. A quick restoration can still recover data that is too old.

For this exercise, measure the time between disruption and service validation, then the gap between disruption and the latest recoverable data point. Define validation beforehand: sign in, retrieve a known record and complete an expected operation.

If recovery meets its time budget but exceeds the acceptable data age, inspect copy frequency, lag and consistency. If data is recent but the service takes too long to return, inspect dependencies, access and validation steps. Retain the exercise log and repeat after correction.

Fictional scene of technicians checking isolated backup equipment. — A fictional recovery rehearsal with no real organisation or incident depicted.

Reference points and evidence to retain

Reference point	What you can conclude	Evidence to retain
RTO objective	Target recovery duration	Agreed scope and starting point
Observed duration	Time until service validation	Timestamps and successful sample operation
RPO objective	Maximum tolerated data age in this exercise	Expected data point and business decision
Observed gap	Age of the data point actually recovered	Data timestamp and consistency check

From observation to decision

Set the objectives
Restore in isolation
Validate the service
Compare both gaps

Demonstrate recovery through the service

Finishing a file copy is one milestone. Validate recovery when the agreed service works with consistent data and expected access. Set RTO and RPO with business owners; NIST does not prescribe the values in this example.

Observed duration: 95 minFrom 09:00 to 10:35
Recovered data age: 45 minLast consistent point at 08:15
RPO margin: −15 min30-minute objective exceeded

Fictional timeline: one clock and one service
Time	Event	What it establishes
08:15	Last consistent recoverable point	Data loss may span 45 minutes before disruption.
09:00	Disruption observed	Start of the recovery interval used in this exercise.
10:10	File copying completed	70 minutes elapsed; functionality is not yet validated.
10:35	Sign-in, known record and operation validated	95 minutes elapsed; compare with the 120-minute RTO.

Times are fictional and use the same time zone. The recoverable point must be consistent across components, not merely recent in one file.

Read both objectives together
RTO	RPO	Exercise decision
Met	Met	Also validate integrity, permissions and dependencies before concluding.
Met	Exceeded	Correct copy freshness or consistency, then repeat.
Exceeded	Met	Reduce dependency, access and validation delays.
Exceeded	Exceeded	Review the recovery chain and business objectives before another attempt.

Passing the calculation does not replace functional evidence.

Checks before concluding

Restore in isolation and check that outgoing connections cannot trigger real messages, payments or jobs.
Check application, database, keys, configuration, identity and dependencies together. A missing component can block a recovery already reported as complete.
Compare a known record, expected volumes and an end-to-end operation. A matching hash verifies a copy but does not by itself guarantee business consistency.

Decision: retain both margins, functional checks and exceptions. Repeat after correction; a successful previous exercise does not establish success for the current version.

Calculation rule

Recovery margin = RTO objective − observed duration. Data margin = RPO objective − observed age. A negative margin indicates an overrun.

Change an assumption

Restoration starts quickly, but when is service back?

In this second exercise, separate from the preceding one, timing follows the agreed start and finish. Times are fictional and use one timezone.

09:00
Service interruption; the recovery objective starts here in this example.
09:25
The team begins technical restoration.
10:10
The essential journey works and its data is checked: 70 minutes after interruption.

Reading exercise: the variations describe fictional situations.

Can recovery be reported as 45 minutes?

New evidence: The technical phase takes 45 minutes, but the agreed target is 60 minutes from interruption.
What changes: Recovery time in this case is 70 minutes, missing the target by 10 minutes. Retain the 25 minutes spent mobilising.

What if the backup is from 08:30?

New evidence: The reference interruption occurs at 09:00 and no later data is recovered.
What changes: The illustrative gap is 30 minutes. Check which business records are actually missing; a file timestamp alone does not establish restored-data consistency.

Management indicators

Indicator	What it measures	First action
Coverage	Priority services with a recent rehearsal	Test services without evidence
Restorability	Copies actually read and validated	Fix unusable copies
Observed time	Time from trigger to working journey	Remove the real bottleneck
Observed loss	Gap between expected data and restored point	Adjust backup frequency or method

Common pitfalls

Treating backup success as proof of restoration
Testing one file without its dependencies
Overwriting or exposing production data in a rehearsal
Claiming a recovery target was met without a measured test

Frequently asked questions

Is a verified backup enough?

It shows that a copy exists or passed a particular check, not that the complete service can recover. A functional test is still needed.

Must production be interrupted?

An isolated environment can expose most first-order blockers without interrupting the live service.

What should be recorded?

The scenario, copies, permissions, timeline, functional result, gaps and owners of corrective actions.

Cyber incidents: recovery decisions and evidence

Two integrity checks: before and after restoration

RC.RP-03 concerns assets used to restore; RC.RP-05 concerns restored assets and services. Backup-job status and file presence do not answer both questions.

Before use, check the candidate under the planned controls and retain origin and acceptance evidence.
After restoration, verify assets, root causes addressed within scope and a business journey with its dependencies.
End recovery against local criteria without confusing that milestone with closure of all corrective work.

Explore NIST outcomes and the timeline →

References reviewed 2026-10-22 · NIST SP 800-61r3 · pp. 27–29, 34–35 · CSF 2.0 · Appendix A

Media: sanitization and evidence

A recovery copy also has a retirement stage

A restoration test establishes a recovery path for a given scope. It does not show that retired media, key copies or out-of-scope data have been sanitized. Plan retirement without undermining validated retention needs.

Connect backup copies, media and keys to owners and scope.
Separate restoration success, retention expiry and sanitization evidence.
Where CE is considered, examine key copies or escrow outside the medium.

Read the methods, evidence points and annotated situations →

NIST · SP 800-88 Rev. 2 · Guidelines for Media Sanitization · Final · 2025-09-26 · consulted 2026-10-23

Official references

References consulted: 23/10/2026. The method and worksheet propose checks to adapt to your context; they do not constitute certification.