Your disaster recovery plan needs a check that catches that last failure. Connect the restore sequence to specific data and function checks before deciding that the service is ready to use. This worked template shows the dependencies, checkpoints, and rehearsal notes for a fictional catalog service.
Name the system and the recovery point
The original example uses Harbor Catalog, a fictional service that connects catalog records with files in private storage. Its teaching fixture contains two expected relationships:
| Catalog record | Expected file |
|---|---|
| A01 | F01 |
| A02 | F02 |
The planned recovery uses storage snapshot ST-7, catalog database checkpoint DB-7, and application build APP-7. These are illustrative identifiers. In your plan, enter the actual backup references, versions, and checkpoints your recovery procedure requires.
A database record and its file need to describe a consistent recovery point. Finding A02 in the database will not help a reader if F02 is absent from the restored storage.
Put dependencies in the restore order
The fictional plan uses this sequence:
| Step | Planned work | Check to record |
|---|---|---|
| 1 | Identify the isolated rehearsal target and the intended recovery sources. | Target reference, ST-7 and DB-7 identities, and APP-7 version. |
| 2 | Restore the private storage snapshot using the system's procedure. | Storage restoration result and references to its checks. |
| 3 | Restore the matching catalog database checkpoint. | Database restoration result and expected A01/F01 and A02/F02 relationships. |
| 4 | Start the application against the restored dependencies. | Application version and dependency configuration checked. |
| 5 | Exercise known catalog lookups and open the linked files. | Actual results for A01/F01 and A02/F02, with exceptions retained. |
| 6 | Review the results against the service's return criteria. | Remaining gaps and the designated owner's decision. |
Select a dependency in the example to see its prerequisite and the check it needs. The order belongs to this teaching system. Your actual system may have additional services, keys, infrastructure, and recovery steps to document.
NIST SP 800-34 Revision 1 describes stepwise recovery procedures and a subsequent phase that validates recovered data and system functions. Sections 4.3 through 4.5 also cover recovery escalation and supporting procedure references. Use your system-specific runbook for the operational steps.
Keep the failed rehearsal visible
Choose Model R1 to inspect the first fictional rehearsal record:
| Check | Model R1 result |
|---|---|
| Application homepage | Loads. |
| A01 lookup and F01 opening | Record found; file opens. |
| A02 lookup | Record found. |
| F02 opening from A02 | File missing. |
The homepage check passes in the model, but the linked-file check exposes incomplete recovery. Record the F02 exception with the affected record, the check performed, and the observed result. Leave the service's return decision open until the required evidence has been reviewed.
Do not replace the failed entry when you investigate it. The exception tells the next person what went wrong and which check needs another attempt.
Add a later check as its own record
Model R2 is a separate hypothetical entry showing A02's link opening F02. It demonstrates how to record a later check against the same expected relationship.
R2 does not rewrite R1's missing-file result. It also does not establish that every recovery check has passed: the entry covers A02/F02. A complete rehearsal record needs the results required by your actual plan, including unresolved exceptions and the return decision.
In the example, switch between R1 and R2 and keep a review note beside them. The comparison should make it clear which result you are looking at and what it covers.
Fill the parts someone will need during a rehearsal
Use the blank plan to prepare these fields:
| Field | What to supply |
|---|---|
| System scope and owner | The service, included components, responsible owner, and contact reference. |
| Recovery objectives | The agreed recovery-time and data-recovery targets, with their source. |
| Recovery sources | Backup location references, checkpoint identifiers, versions, and how their compatibility is checked. |
| Dependencies and procedures | Restore order, prerequisites, and the maintained runbook reference for each step. |
| Validation | Expected data and functions, the actual check, result, evidence reference, and exception. |
| Return decision | Criteria, designated decision owner, actual decision, and remaining conditions. |
| Rehearsal record | Date, environment, participants, findings, and changes to make before the next rehearsal. |
Keep credentials and sensitive infrastructure details in their established secure location. A review copy can point to the controlled procedure without carrying its secrets.
Build review copy organizes the supplied plan and flags a missing checkpoint or validation description. It does not restore data or test a real service.
Prepare an HTML review copy
Create one complete, self-contained HTML disaster recovery plan review copy.
System scope and responsible owner/contact reference: [PASTE]
Agreed recovery objectives and their source: [PASTE]
Rehearsal environment and isolation checks: [PASTE]
Backup/checkpoint/build references: [PASTE]
Dependency order and maintained procedure references: [PASTE]
Expected data relationships and functional checks: [PASTE]
Return criteria and decision owner: [PASTE]
Actual rehearsal results, exceptions, dates, and evidence: [PASTE OR LEAVE BLANK]
Show dependencies with their prerequisites and validation requirements.
Keep planned steps separate from observed results. For each check, show
expected result, observed result, evidence reference, and unresolved gap.
Do not mark recovery complete because a homepage loads.
When supplied, show original and later rehearsal records separately.
Never overwrite an earlier failure with a later result or treat one
rechecked file as proof of the whole service. Label teaching records
fictional. Do not invent executed commands, restored data, or decisions.
Include a blank plan builder that names missing scope, checkpoint,
validation, or return criteria. Preserve typed notes when switching
records, mark an old generated review stale after edits, and ask before
resetting typed work. No live restore, production access, stored secrets,
network requests, or claims of saved operational records.
Use labeled keyboard-accessible controls, text of at least 16px, and
a layout readable at 360px without horizontal scrolling. Put CSS and
JavaScript inline and return the complete HTML.
Make the next rehearsal check explicit
For Harbor Catalog, the useful follow-up is to locate the cause of the missing F02 and repeat the affected record-and-file check. Update the maintained recovery procedure with what the team learns, then plan the next rehearsal around the remaining gaps.
An HTML review copy in NOS can put the dependency map and validation wording in front of a colleague. Edit the static check description on the page if the review reveals an ambiguity, and share the saved reading copy. Colleagues reopening the existing active link can read the correction; keep the actual rehearsal evidence and return decision with your recovery records.