River
Y CombinatorBacked by Y Combinator
Log InStart Free
FREE TEMPLATE

Technical Disaster Recovery Plan Template

Five documents and five sheets, including a verification log keyed on restores attempted rather than on backup jobs that reported success.

Edit with AIDownload (.docx + .csv)

Free download  ·  No account needed

What you get

Pack of 10 files: 5 documents, 5 spreadsheets

Technical Disaster Recovery Plan Template
  • Why a Green Backup Dashboard Says NothingDocument
  • Worked Example, HalstowDocument
  • Recovery PlanDocument
  • Test ProcedureDocument
  • Communication PlanDocument
  • Recovery Objective by ServiceSpreadsheet
  • Backup Verification LogSpreadsheet
  • Recovery OrderSpreadsheet
  • Recovery Time BreakdownSpreadsheet
  • Test Result HistorySpreadsheet

Every backup job is green. That is a fact about the jobs: a process ran, read some bytes and wrote them somewhere, and nothing in it ever tried to bring a system back. In the worked example here, 34 of 34 jobs were green, 11 of those 34 systems had ever had a restore attempted, and 5 of the 11 attempts failed. Not one failed on a bad backup. They failed on broken replication, a slow storage tier, a key held inside the blast radius, and two restores that came up on default settings.

Two of those five are documented behaviour rather than misconfiguration. AWS states that you cannot restore a snapshot into an existing instance and that the new one loads its data in the background while already reporting itself available. Recovery points drift the same way: point-in-time recovery ships its transaction logs every five minutes, so an objective of zero against it is unachievable rather than ambitious.

So the pack measures four things instead of restating a plan. What has actually been restored. What each mechanism's recovery floor really is, beside the number somebody wrote down. How long a recovery takes from detection rather than from the restore command, which at Halstow was 185 minutes against a stated 60. And whether the recovery order can be executed at all, because a plan sorted by business criticality starts with the service that needs five other things running first.

Thirty-four green backups, eleven restores, five failures

Three sheets from one estate. What has actually been restored, where the recovery time really goes, and the order the plan has to run in.

Technical Disaster Recovery Plan Template
RiverBackup Verification

Backup Verification Log

Illustrative rows for a fictional logistics platform, Halstow, with 41 services. Keyed on restores attempted, not on backup jobs. Never attempted is a state, not a blank cell.

DateSystemElapsedOutcomeWhat failedWhere the failure lived
2026-02-11Orders database185 minpass with findings82% of the elapsed time sat outside the restore stepprocess
2026-02-04Billing ledgeraborted at 51 minfailSnapshot encrypted with a key held in the account being recovered fromkey custody
2026-01-28Rating engine DB74 minfailRestored onto the default parameter group; refused every application connectionconfiguration
2026-01-21Partner API DB63 minfailRestored into the default security group; nothing could route to itnetwork
2025-11-06Orders search index140 minfailBacked up from a replica whose replication had broken 6 weeks earlierbackup source
2025-09-17Customer document storeaborted at 12 hfailObjects had aged into a tier with a 12-hour retrievalstorage tier
2025-06-12Analytics warehouse206 minpassnonen/a
never attempted23 further servicesn/auntestedNothing has ever been triedunknown

Thirty-four green jobs, eleven systems ever restored, five failures. And not one of the five was a bad backup. Every failure is in the machinery around the data: what the backup read from, where the key lives, what tier the objects aged into, what configuration a restored instance inherits.

Two of them are documented behaviour. A restored database instance takes the default parameter group and the default network permissions unless the restore call names others. Both restores succeeded. Neither system could be used.

The bottom row is the real finding. Twenty-three systems have a backup, a green dashboard, a recovery objective in a plan, and no evidence of any kind that they can come back.

RiverRecovery Time

Recovery Time Breakdown

The orders database, stated at one hour, measured end to end from the moment a monitor would have fired.

StepMinutesIn the stated hourFixSaves
Detection: a monitor fires and pages somebody4nonone needed0
Decision: declare a disaster and invoke the plan22noMake declaring a single scripted command16
Locate the right snapshot, confirm its timestamp9noName snapshots by recovery point0
Restore until status reaches available34yesprovider operation0
Reattach the parameter group and security group17noName both in the restore call17
Repoint the application, then DNS at a 300s TTL13noLower the TTL before a planned cutover9
Warm the instance against background loading28noA scripted scan set rather than ad hoc queries21
Reconcile the five-minute transaction gap41noBuild the reconciliation query in advance26
Verify: smoke tests plus one business check17nonone yet0
MEASURED TOTAL185stated 60after the fixes: 9689

The restore is 34 of 185 minutes, which is 18 percent. That is why the one-hour figure had survived years of review: the step everybody pictures does fit inside an hour. Thirty-five minutes elapse before it starts and 116 after it reports success, so 82 percent of the recovery sits outside the part being estimated.

The warming step is not padding. A restored instance reports itself available and continues loading its data in the background, serving early reads from object storage on demand. Halstow’s first query against a cold table took eleven seconds and nothing was broken.

None of the five fixes worth 89 minutes is clever, and none of them was findable without running the thing once.

RiverRecovery Order

Recovery Order

The same 41 services, sorted by what each one needs before it can start, against the criticality order the plan was written in.

By dependencyServiceBy criticalityTierNeeded byMove
1Internal DNS29unclassified31 services+28
2Certificate issuance34unclassified26 services+32
3Shared Postgres cluster2233 foundations+19
4Secrets store18324 services+14
5Identity provider16322 services+11
6Service registry25319 services+19
9Orders database419 services-5
11Checkout service11nothing-10

The criticality-ordered plan could not be executed. Run top down, nine of its first twelve steps blocked on something further down the list, and the first step that could actually run was number four. Checkout is position one by criticality and position eleven by dependency, because it authenticates against the identity provider, reads its credentials from the secrets store, and resolves both through internal DNS.

Eight services turned out to be foundations that something else needed first. Five were classified tier three and three were not classified as services at all, which is how internal DNS ends up at position 29 in a plan that 31 services depend on.

Sorted properly, six of the eight foundations occupy the first eight positions and the first revenue-facing service lands at eleven. It looks wrong on a slide and it is the only order that runs.

Edit with AI

What's in the pack

01

Backup Verification Log

One row per restore attempt rather than per backup job, with the elapsed time, what failed, and whether the failure was in the data or around it.

02

Recovery Objective by Service

Stated recovery point, the mechanism behind it, and what that mechanism can actually deliver, as three separate columns that never overwrite each other.

03

Recovery Time Breakdown

Nine steps from detection to verification with minutes against each, so the restore stops standing in for the recovery it is a fifth of.

04

Recovery Order

The estate sorted by what each service needs at startup, beside the criticality order, with the disagreement expressed in positions moved.

05

Test Result History

Every exercise with its class named, because a tabletop and a real restore are both called tested and only one of them finds a broken replica.

06

Recovery Plan and Test Procedure

The plan organised by what is lost rather than what caused it, and the procedure for running a functional test that has not been quietly made easier.

07

Communication Plan

Who is told what during a recovery measured in hours, including the fallback channel that does not authenticate through the system being recovered.

How to use it

  1. 1

    Open in River, or take it blank

    Send the pack your service inventory and backup configuration inside River, or download the five documents and five sheets and work through them without an account.

  2. 2

    Count restores, not backups

    Four states per system: restored recently, restored once long ago, never restored, or no backup at all. The last two are where the work is.

  3. 3

    Check every objective against its mechanism

    The stated figure stays. The mechanism's floor goes next to it, and the gap between them is the finding rather than an error to correct.

  4. 4

    Time one recovery end to end

    From the moment a monitor would have fired, not from the restore command, with minutes against each step so the fixes have somewhere to land.

Frequently asked questions

Is this template free?

Yes, and the download needs no account and no card. Edit with AI is the optional half: it reads the inventory and backup configuration you send, works out what has never been restored, and checks each objective against its mechanism. Every other pack sits in the template library.

What format are the downloaded files?

Word (.docx) for the five documents and CSV (.csv) for the five sheets, zipped together, with nothing to convert on either side. The columns that matter are already there: each mechanism's floor beside the objective somebody stated, minutes against every recovery step, and the class of each test rather than just its date.

Our backups have been green for years. What is the risk?

That the green is describing the job rather than the data. Halstow's five restore failures were a replica that had stopped replicating, objects in a slow retrieval tier, a key inside the blast radius, and two default configurations. A backup job cannot see any of those.

How is this different from a business continuity plan?

Scope. A continuity plan covers processes, people and manual workarounds, and belongs with the business continuity pack. This one covers whether the systems come back: restore evidence, recovery-point floors, measured recovery times and an executable order.

We run an annual DR exercise. Does that count?

It depends which class it was. NIST SP 800-34 describes a tabletop as discussion-based only, not involving the deployment of equipment. Halstow's exercise covered all 41 services and four had ever had a real restore.

Why sort recovery by dependency instead of importance?

Because importance is not an order you can execute. Nine of the first twelve steps of Halstow's criticality-ordered plan blocked on something further down the list. Checkout sat at position one and could not start until the identity, secrets and DNS services at positions 16, 18 and 29 were up.

What else belongs alongside this?

The two things that decide whether you notice and whether you can act. A failure mode review finds what breaks and what would go undetected, and the SLO pack sets what counts as unavailable in the first place. Telling customers while it happens is the incident communication pack.

Sources

  1. AWS DocumentationRestoring to a DB instance (opens in a new tab)
  2. AWS DocumentationRestoring a DB instance to a specified time for Amazon RDS (opens in a new tab)
  3. NISTNIST 800-34, Rev 1 Contingency Planning Guide for Federal Information Systems (opens in a new tab)

Written by

Chandler Supple

Co-founder & CEO, River

Chandler has spent the last six years working in AI, building tools for millions of users and Fortune 100 companies. In 2025, he co-founded River to build a new kind of operating system for AI agents.

LinkedInGitHubX

Reviewed by

Brian Joseff, Co-founder, River

LinkedInX

More free templates

Incident Status Page Update Template

Free incident status page update template that records what you promised beside what you posted, so the silence between two updates becomes a measurable number.

Monthly Reliability Review and Toil Estimate

Free monthly reliability review template that prices operational load in engineer-days and names the quarter it crosses your engineering floor.

On-Call Handbook and Runbook Coverage

Free on-call handbook template that computes runbook coverage from your alert rules, separates current runbooks from stale ones, and weights it by night pages.

SLO and Error Budget Template

Free SLO definition template in Word and CSV, with a register that puts trailing attainment beside every reliability target you have already promised.

Find out which systems have ever come back

Take the Word documents and CSV sheets blank, or open this exact pack in River and send it the inventory and backup configuration you already have.

Edit with AI