A disaster recovery plan is a documented recovery system that defines how a team restores critical infrastructure, applications, and data after a serious disruption.
For a small technical team, the plan needs to be executable under pressure. It should identify what must recover first, which recovery point is acceptable, who owns each action, what evidence proves recovery, and when public traffic can safely return. A document that only lists backup tools or emergency contacts is not yet a usable recovery plan.
At Raff Technologies, we use a dependency-first recovery model in our guidance: restore trusted access, network paths, durable data, and core application services before optional workers, scheduled jobs, and normal traffic.
This guide gives small teams a disaster recovery runbook and checklist they can adapt to their own stack. For the difference between availability and recovery planning, read High Availability vs Disaster Recovery.
Disaster recovery plan template for a small team
A useful disaster recovery plan can fit into one working document if every field has a real owner and recovery source.
| Field | What to record |
|---|---|
| Service / workload | Name of the production service being recovered |
| Business owner | Person who decides acceptable business impact |
| Technical owner | Person responsible for the recovery action |
| RPO | Maximum acceptable data loss |
| RTO | Maximum acceptable recovery time |
| Failure scope | VM, database, storage, credential, deployment, or security event |
| Trusted recovery source | Named backup, snapshot, replica, image, repository, or export |
| Dependency order | What must recover before this service |
| Recovery action | Restore, rebuild, fail over, or repair |
| Validation | Health checks, data checks, and critical user journeys |
| Stop condition | Evidence required before moving to the next phase |
| Traffic return | Who approves reopening traffic and background jobs |
| Escalation | Contact or decision path when the runbook cannot proceed |
Example:
Service: customer-api RPO: 30 minutes RTO: 2 hours Recovery source: latest approved database backup + application release Owner: platform engineer Dependencies: credentials -> private network -> database -> API Validation: login, read/write test, one critical API flow Traffic return: incident lead after a stable observation window
The numbers above are examples, not recommended targets. Set RPO and RTO from business impact and tested recovery capability.
A disaster recovery plan defines the path back to service
A disaster recovery plan should answer what the team will do after normal availability mechanisms are no longer enough.
That can include incidents such as:
- a VM or storage failure that requires recovery from a backup;
- a destructive deployment or operating-system change;
- corrupted application or database state;
- accidental deletion that has already propagated;
- loss of credentials or configuration required to run the service;
- a security incident that requires rebuilding from a trusted point;
- a network or dependency failure that requires traffic to move or remain disabled;
- a recovery process that exceeds the normal incident-response path.
A disaster recovery plan is related to incident response, but it is not the same document. Incident response focuses on detection, containment, diagnosis, ownership, and service restoration. Disaster recovery focuses on rebuilding or restoring the technology and data required to return to a trusted operating state.
Use Incident Response Plan for Small Teams for the broader incident process. The two documents should point to each other.
The decision framework starts with recovery objectives and failure scope
Do not begin a disaster by asking which backup button to click. Begin with the impact, the required recovery point, and the acceptable recovery time.
| Decision | Question | Output |
|---|---|---|
| Failure scope | What is unavailable or untrusted? | Affected services and dependencies |
| Recovery Point Objective (RPO) | How much recent data can the business lose? | Latest acceptable recovery point |
| Recovery Time Objective (RTO) | How long can the service remain unavailable? | Recovery deadline |
| Recovery mode | Restore, rebuild, fail over, or repair in place? | Chosen path |
| Data authority | Which copy of data is trusted? | Named backup, snapshot, replica, or source |
| Recovery order | Which dependency must return before another? | Ordered sequence |
| Traffic decision | When can users return? | Go/no-go criteria |
| Evidence | What proves recovery? | Health, data, logs, and user-flow checks |
Use restore when a known-good recovery point is the fastest safe route back.
Use rebuild when the current host or configuration cannot be trusted and the workload can be recreated from code, configuration, and external data.
Use failover when a prepared alternate service or replica already exists and the failure model is covered by that architecture.
Use repair in place only when the failure is understood, the current environment remains trustworthy, and repair is safer than restoration or rebuild.
A useful rule is: the fastest technical action is not always the fastest path to confidence. Recovery is complete only when the team trusts the data and application behavior again.
The runbook begins with an inventory and dependency order
A small team can keep the inventory compact, but it must be current enough to use during an outage.
For every production workload, record:
- service name and owner;
- public hostname or entry point;
- VM, managed database, volume, bucket, or external dependency;
- configuration source;
- secret source;
- backup or recovery source;
- expected recovery point;
- startup dependencies;
- downstream side effects;
- health check;
- critical user journey;
- recovery owner and backup owner.
Then convert the inventory into dependency order.
A common application recovery sequence is:
1. Administrative access and trusted credentials 2. Private networking and firewall path 3. Durable database and persistent storage 4. Core application service 5. Internal APIs and service dependencies 6. Cache and queue layer 7. Background workers and scheduled jobs 8. Public routing and normal traffic 9. Non-critical analytics, exports, and secondary services
The exact order can differ. The important part is that it is explicit before the incident.
For example, bringing a worker fleet online before its database is restored can create retry storms. Bringing public traffic back before payment, authentication, or storage is validated can turn a recovery into a second incident.
The disaster recovery runbook assigns owners and stop conditions
A runbook should be short enough to follow while the team is under pressure.
Use one row per recovery action:
| Phase | Owner | Action | Evidence | Stop condition |
|---|---|---|---|---|
| Declare | Incident lead | Declare DR mode and freeze risky changes | Incident channel and timestamp | Scope is understood enough to select a path |
| Select point | Data owner | Choose the latest trusted recovery point within RPO | Backup timestamp and reason | Recovery point is approved |
| Recover data | Infrastructure owner | Restore or rebuild required data layer | Service opens and integrity checks pass | Data is trusted |
| Recover app | Application owner | Deploy or restore application services | Health checks pass | Core service is stable |
| Validate | Validation owner | Test critical user journeys and side effects | Recorded results | No critical blocker remains |
| Observe | Incident lead | Watch metrics, logs, queues, errors, and saturation | Stable telemetry window | Recovery remains stable |
| Restore traffic | Incident lead | Re-enable normal traffic and jobs in stages | User-facing SLIs remain healthy | Normal service is confirmed |
| Close | Incident lead | Record timing, gaps, and follow-up work | Recovery log and tasks | Owners and deadlines exist |
The stop condition matters. Without one, teams can advance because a command completed rather than because the system is ready.
Your actual runbook should also include the direct links required during recovery: console pages, dashboards, secret manager, DNS or traffic controls, backup locations, deployment repository, status channel, and escalation contacts.
Do not store sensitive credentials directly in the runbook.
Recovery validation proves more than server uptime
A VM that boots is not the same as an application that has recovered.
Validation should cover four layers.
Infrastructure validation
Confirm:
- expected VM or service state;
- disks and volumes are attached correctly;
- private network paths work;
- firewall rules match the recovery architecture;
- sufficient disk capacity exists;
- system services have no unexplained failures.
Data validation
Confirm:
- the intended recovery point was used;
- database schemas or collections are present;
- a known record matches the expected point in time;
- object or file paths resolve correctly;
- application reads work;
- a controlled write test works where safe;
- no newer untrusted data has been mixed into the recovered state.
Application validation
Test a small number of critical journeys, such as:
Authentication Create or read a core business record Upload or retrieve a required file Run one critical API request Complete one safe background job
Choose journeys that represent the business rather than checking every endpoint.
Side-effect validation
Before reenabling workers and scheduled jobs, verify that recovery will not:
- send duplicate emails;
- replay payment actions;
- send old webhooks;
- execute queued jobs twice;
- overwrite newer external data;
- trigger duplicate exports or reports.
The recovery owner should sign off on evidence, not only on infrastructure status.
Observability determines when traffic can return
The roadmap back to service needs a measurement layer. A recovered system should not return to full traffic merely because its health endpoint answers 200.
Use Application Observability for Small Teams to define the metrics, logs, and alerts that support the recovery decision.
During recovery, watch at least:
- user-facing error rate;
- p50 and tail latency for critical requests;
- database connections and query errors;
- queue depth and oldest-job age;
- CPU and memory saturation;
- disk capacity and I/O errors;
- application restart count;
- authentication failures;
- external dependency errors;
- backup or recovery job status where relevant.
Restore traffic in stages when the architecture allows it. A useful pattern is:
Internal validation -> limited traffic -> observe critical signals -> enable workers carefully -> broader traffic -> defined observation window -> normal operation
The team should define the observation window in advance. Five minutes may be enough for a low-risk internal service; a critical customer system may need a longer period that covers real requests, worker activity, and database writes.
A disaster recovery plan without observability has no objective signal for deciding when recovery is stable.
Recovery exercises turn the plan into evidence
A written disaster recovery plan is useful before the first test, but it becomes credible only after the team exercises its parts.
Use increasing levels of realism:
| Exercise | What it tests | Production risk |
|---|---|---|
| Document review | Contacts, links, recovery order, ownership | Very low |
| Tabletop exercise | Decision-making against a scenario | Low |
| Component restore | One backup, database, VM, volume, or configuration path | Low to medium |
| Isolated application restore | App + data + network validation away from live traffic | Medium |
| Full recovery exercise | End-to-end recovery and traffic decision | Highest; requires planning |
Review the runbook on a risk-based cadence and whenever architecture, recovery tooling, ownership, credentials, or backup paths materially change. Exercise a meaningful recovery path often enough to keep the documented steps credible for the workload's risk and recovery objectives.
Record:
- scenario;
- recovery point;
- start time;
- time to trusted data;
- time to healthy application;
- time to safe traffic;
- manual interventions;
- missing credentials or documentation;
- unexpected dependencies;
- actual RPO and RTO achieved;
- owners for each remediation.
The existing Restore Testing Checklist for Production VMs covers the evidence a VM restore should produce. A future transactional restore tutorial should only be published after its complete procedure has been tested end to end on Raff infrastructure; this runbook does not substitute for that test.
Raff provides recovery building blocks, not the recovery decision
Raff gives small teams several infrastructure components that can support a disaster recovery plan.
Raff Data Protection provides VM backup and recovery capabilities that can support a disaster recovery plan. Keep schedule, retention, restore behavior, and current product limits in the runbook as links to live product documentation rather than copying mutable platform limits into an evergreen guide. Before an incident, verify whether the planned recovery path restores in place, creates a separate recovery environment, or requires an additional rebuild step.
For independent files, database exports, configuration archives, and recovery artifacts, Raff Object Storage provides an S3-compatible storage path. Object storage can help keep recovery artifacts outside the application VM when your backup tooling supports that model.
Raff VPC can keep application, database, and internal recovery traffic on private network paths. Raff Volumes provide persistent block storage and support volume snapshots for data that needs a disk-like interface.
The Raff-specific recovery map can be kept simple:
VM or application failure -> choose trusted recovery point -> use Data Protection when VM backup recovery is the right path Database or file recovery -> use database-aware backup / PITR where applicable -> use Object Storage for independent archives and exports Rebuild path -> deploy compute again -> reconnect VPC and persistent data -> deploy application -> validate before public traffic
The platform can provide recovery mechanisms. Your team still decides the trusted recovery point, recovery order, acceptable data loss, validation criteria, and when service is safe for users again.