A disaster recovery (DR) plan is a documented, tested procedure for restoring service after a major failure — written in advance, when you can think clearly, not improvised during an actual crisis.
Why You Need a Written Plan
During a genuine outage, stress and time pressure make it easy to forget steps or make mistakes. A written plan removes the need to remember everything under pressure.
Step 1 — Define Recovery Objectives
RTO (Recovery Time Objective) — how long can you tolerate being down? (e.g. "4 hours")
RPO (Recovery Point Objective) — how much data loss is acceptable? (e.g. "up to 24 hours of data" if backups run daily)
These two numbers drive every other decision in your plan — a 15-minute RTO requires very different infrastructure than a 24-hour RTO.
Step 2 — Identify Failure Scenarios to Plan For
- VPS becomes completely unreachable (hardware failure, provider outage)
- Data corruption or accidental deletion
- Security compromise requiring a clean rebuild
- Accidental misconfiguration causing an outage
Step 3 — Document Your Infrastructure Inventory
Keep a current, accessible (but securely stored) document listing:
- All servers, their providers, and access credentials location
- DNS provider and how to access it
- SSL certificate details and renewal process
- Third-party service dependencies (payment processor, email provider)
Step 4 — Write Step-by-Step Recovery Procedures
For each failure scenario, document the exact recovery steps:
SCENARIO: Complete VPS Failure
1. Provision new VPS with [provider], matching spec: [details]
2. Install base OS and run: [link to hardening checklist]
3. Restore latest database backup from: [location]
Command: gunzip -c latest-backup.sql.gz | mysql -u root
4. Restore application files from: [location]
Command: rsync -avz backup-server:/backups/www/ /var/www/
5. Update DNS A record to new server IP
6. Verify application functionality: [checklist]
7. Monitor closely for [timeframe]Step 5 — Identify Who's Responsible
Even for a one-person operation, document who's expected to respond and how to reach them (or, for teams, an on-call rotation and escalation path).
Step 6 — Store the Plan Somewhere Accessible During an Outage
Critically: don't store your only copy of the recovery plan on the VPS that might be the thing that's down. Keep it somewhere independently accessible.
Step 7 — Test the Plan
Periodically run through the actual recovery steps (ideally on a test environment) to confirm the documentation is accurate and complete — plans that are never tested tend to have gaps that only surface during a real incident.
Step 8 — Review and Update Regularly
Revisit the plan whenever your infrastructure changes significantly — a new service added, a provider switched, a credential rotated — outdated recovery documentation can be as dangerous as having none.
DR Plan Checklist
- RTO and RPO explicitly defined
- Failure scenarios identified
- Infrastructure inventory documented and current
- Step-by-step recovery procedures written for each scenario
- Plan stored independently of the infrastructure it describes
- Plan tested at least annually, or after major changes
Common Mistakes
- Writing a plan once and never updating it as infrastructure evolves
- Storing the plan only on the primary server it's meant to help recover
- Never actually testing whether the documented steps work in practice
Related Articles
- Backup Strategy 101: The 3-2-1 Rule Explained
- How to Test and Verify Your Backups Actually Work
- How to Migrate a Database to a New VPS
