Disaster Recovery Plan Example: A Walkthrough + Checklist

TL;DR. A disaster recovery plan example is only useful if you copy the structure, not the prose. The structure is: what you’re protecting, how fast it has to come back (RTO), how much data you can lose (RPO), who does what, and the exact restore steps. The rule every template skips: the plan has to live somewhere the disaster can’t reach. A recovery plan stored only in the system that’s down is not a plan.

Most disaster recovery plans are written once, filed somewhere proud, and read for the first time during the disaster. That is roughly the worst possible moment to discover your only copy was on the file server that just caught fire. A disaster recovery plan example is genuinely useful — but only the skeleton travels. The words are yours; the shape is the part worth stealing.

This post is the shape. A worked example section by section, a checklist you can run down, the two numbers the whole thing turns on, and the honest part about when a one-pager beats a fifteen- section binder.

What a disaster recovery plan actually is

A disaster recovery plan is the documented procedure for restoring your IT systems and data after an outage, attack, or physical failure. It names what must come back, in what order, how fast, and who runs each step. It is not a backup. A backup is a copy; the plan is the part that turns the copy back into a running business.

That distinction is the whole point, so it is worth being blunt about. The importance of a disaster recovery plan is not that it prevents disasters — nothing prevents disasters. It is that it turns a panicked, improvised, 3 a.m. guessing game into a checklist someone can follow while their hands are shaking. The test of a plan is not how thorough it reads. It is whether a tired person can execute it under pressure without you in the room. Most plans fail that test because they were written to be audited, not run.

The authoritative reference here, if you want one, is NIST SP 800-34, the federal contingency-planning guide. It is long. The example below is the short version that fits the way teams actually work.

A disaster recovery plan example, section by section

Here is the worked example. These are the disaster recovery plan steps in the order a plan should present them — not the order you build them, but the order the person executing reads them.

Scope and purpose. One paragraph. What this plan covers (production database, app servers, customer data) and explicitly what it does not (the marketing site, the office Wi-Fi). A plan that claims to cover everything covers nothing.
Recovery objectives. The RTO and RPO for each critical system, stated as numbers, not adjectives. “Database back within 2 hours, no more than 15 minutes of data lost.” More on these below — they are the spine.
Roles and contacts. Who declares a disaster. Who runs recovery. Who talks to customers. Names and phone numbers, not job titles — titles do not answer the phone at 3 a.m.
Asset inventory and priority. Every system, tagged critical / important / deferrable. Critical comes back first. The argument about what’s critical happens now, in the meeting, not during the outage.
Backup and restore detail. Where backups live, how often they run, and the literal restore commands. The Ready.gov guidance and most practitioners land on the 3-2-1 rule: three copies, two media, one off-site. The off-site copy is the one that matters here.
Recovery procedures. The step-by-step runbook for bringing each critical system back, in dependency order. This is the part people skip and the part that saves you. It should read like a runbook, because it is one.
Communication plan. What you tell customers, when, and through which channel — including the channel that still works when your main one is down.
Testing and maintenance. When the plan is tested, how, and who owns keeping it current. A plan last revised two reorganisations ago is fiction with a version number.

Copy those eight headings. Fill them with your systems, your numbers, your names. That is a disaster recovery plan example turned into your disaster recovery plan in an afternoon.

To make it concrete, here is one critical-system entry filled in, the way it should actually read on the page:

System: Primary Postgres (customer data). Priority: Critical. RTO: 2 hours. RPO: 15 minutes. Owner: Priya (on-call), +1-555-0148. Backups: continuous WAL archiving to off-site object storage; nightly full. Restore: (1) provision standby from latest base backup; (2) replay WAL to last archived segment; (3) verify row counts against the monitoring snapshot; (4) cut DNS over; (5) confirm app health check green. Last tested: restored in staging 2026-04-30, 38 minutes end to end.

That is the difference between a plan and a poster: a stranger on-call could run those five steps at 3 a.m. without you. Two of your disaster recovery plan examples done to that depth beat fifteen systems described in adjectives.

The disaster recovery plan checklist

The example above is the document. This is the disaster recovery plan checklist — the run-down you use to confirm the document is real and not aspirational:

Business impact analysis done — you know what an hour of downtime actually costs, per system.
RTO and RPO set per critical system, in numbers, signed off by someone who owns the budget.
Backups exist, run on a schedule, and — this is the one — have been restored in a test, not just written.
The off-site copy is genuinely off-site and not the same building with a different door.
Roles assigned to named people with working phone numbers.
Recovery procedures written as executable steps, not summaries.
The plan is readable when the primary systems are down.
The plan has been tested in the last six months.
Someone’s name is on “keep this current,” and they know it.

If you can tick all nine honestly, you have a plan. If you ticked “backups exist” but skipped “backups have been restored,” you have a hypothesis. (Patches, who runs reliability around here and keeps a butterfly net by the desk for incidents that get loose, has a rule: an untested backup is a rumour. We are not going to argue with Patches.)

RTO and RPO: the two numbers the plan turns on

Every disaster recovery plan example online lists RTO and RPO, and most bury what they mean under an acronym. Here it is plainly:

Term	What it caps	Example	Set by
RTO — Recovery Time Objective	How long you can be down	”Back online within 2 hours”	The cost of downtime
RPO — Recovery Point Objective	How much data you can lose	”No more than 15 minutes of data”	How often you back up

RTO drives your recovery architecture: a 2-hour RTO and a two-day-restore backup strategy are incompatible, and the plan is where you find that out cheaply instead of expensively. RPO drives backup frequency: if you can lose at most 15 minutes, a nightly backup is already a broken promise.

These are the same family of numbers as the ones in SLOs and SLAs — a target stated precisely enough that you can tell, afterward, whether you hit it. A recovery objective without a number is a feeling.

Disaster recovery is not business continuity

People search for “disaster recovery and business continuity plan” as if it were one document. It is two, and conflating them is why plans get bloated and unused.

Disaster recovery is the IT half: restore the systems and the data. Servers, databases, backups, restore steps.
Business continuity is the everything-else half: how the business keeps operating while IT recovers. Where people work, how orders still get taken, who has signing authority if the usual person is unreachable.

A disaster recovery plan is a chapter of the business continuity plan, not a synonym for it. Keep them separate documents that reference each other. The recovery plan should be short enough to execute under stress; the continuity plan can be the longer, calmer read. The international standard for the continuity half is ISO 22301; the recovery half is the one this post is about. A worked example: a flooded office is a continuity problem (where do people work tomorrow) and the down file server inside it is a recovery problem (restore from the off-site copy by the 2-hour RTO). Same disaster, two plans, two owners. Trying to make one document do both produces a binder nobody opens — which is the same failure mode covered in knowledge management: the information exists, but not in a form anyone can act on.

The plan has to outlive the disaster

Here is the part the templates skip, and the opinion this post stands behind: a disaster recovery plan that lives only inside the system the disaster takes down is not a plan. It is a wish with a table of contents.

Two quarters before anyone built our internal wiki, Lord Circuitrix issued a one-line infrastructure decree — provision a Postgres container in case someone builds something — and a database nobody had asked for sat there, running, doing nothing, for months. On the night it was finally needed, it was already up. That is the entire theory of disaster recovery compressed into one decree nobody argued with: the thing you need during the disaster has to exist before the disaster, somewhere the disaster does not reach.

Apply it to the plan itself. Raccoon Corp runs its own incident records, runbooks, and recovery procedures in Raccoon Page — the same wiki we sell, dogfooded on the instance we trust most. And every plan exports as Obsidian-compatible Markdown on every plan tier, any time, so a current copy can live on a laptop, in a repo, in a second location — anywhere the outage can’t follow. You’re never locked in, which for a recovery document is not a data-portability nicety; it is the entire requirement. A plan you cannot read during the disaster fails at exactly the moment it exists for.

Practically: keep the canonical plan in a fast wiki so it stays current and searchable, and keep an exported Markdown copy somewhere offline. The incident response playbook is its companion — the playbook is what you run during the hit; the recovery plan is how you get back. After both fire, you write the postmortem.

When you don’t need a formal DR plan

Honesty section, because every post here gets one. Not every team needs a fifteen-section recovery binder, and pretending otherwise sells dread, not software.

If you are a two-person shop running on managed services with automated backups, your disaster recovery plan can be one page: where the backups are, the provider’s restore procedure, who to call, and the support number. That is a complete plan for that scale. Write the index card and stop.

Raccoon Page is overkill for a team whose entire recovery procedure fits on an index card — we’d rather say that than sell you a process you won’t run. The formal plan earns its weight when downtime has a real per-hour cost, when more than one person has to execute it, and when “who restores the database” cannot be answered with “the one person who knows.” Below that line, keep it short. Above it, keep it somewhere the fire can’t reach.

Things people actually ask

What is a disaster recovery plan example? A worked template showing the sections a real plan needs — scope, RTO/RPO, roles, asset priority, backup and restore detail, recovery procedures, communication, and testing. Copy the structure; the content has to be your own systems and numbers.

What are the steps of a disaster recovery plan? Scope, recovery objectives, roles and contacts, asset inventory, backup and restore detail, recovery procedures, communication, and testing and maintenance. Present them in execution order, not build order.

What should a disaster recovery plan include? At minimum: per-system RTO and RPO, an off-site backup, named people with phone numbers, executable restore procedures, and a copy that is readable when production is down. Everything else is useful; those are non-negotiable.

What is the difference between RTO and RPO? RTO caps how long you can be down; RPO caps how much data you can lose. RTO shapes your recovery architecture; RPO shapes your backup frequency. Both are numbers, not adjectives.

Is a disaster recovery plan the same as a business continuity plan? No. Disaster recovery restores IT systems and data. Business continuity keeps the business running while that happens. Recovery is a chapter of continuity, not a synonym — keep them as separate, cross-referencing documents.

How often should a disaster recovery plan be tested? At least every six months, and after any material infrastructure change. Test by restoring, not by re-reading. An untested plan and an untested backup share the same status: rumour.

Why is a disaster recovery plan important? Because the alternative is improvising recovery while customers, revenue, and your own stress level are all on fire. The plan converts a panic into a procedure. That conversion is the entire value.

The honest version of the disaster-recovery question is short: what comes back, how fast, who does it, and can you still read the plan when everything is down. Steal the structure from any disaster recovery plan example, fill it with your real numbers, test the restore, and keep an exported copy where the outage can’t reach it. We built Raccoon Page to be the fast, searchable, exportable place the canonical version lives — free for super-lean teams, no credit card required, and your wiki exports as Markdown the day you want it elsewhere. Worst case, you test the plan and nothing breaks. Best case, the night it matters, the plan is already up — like a Postgres container nobody remembers asking for.