Automatic backup ran two years. On outage day, nobody knew how to restore: wrong snapshot, corrupt database, DNS still pointing to old server. « We had backups » — yes. No recovery plan.
This scenario repeats whenever a team confuses copy with continuity. A DRP answers precise questions: how long can you stay down (RTO), how much data can you lose (RPO), who does what, in what order, and how to inform customers and partners. Host backups are one brick — not the plan. Cross-check The 99.99% myth: SLA credits never replace an organisation that knows how to bounce back.
Define business RTO and RPO
RTO and RPO are not chosen by technical gut feel. They translate business risk tolerance: lost sales, inability to invoice, contractual breach with a B2B client. Start with a simple table validated with product or leadership.
| Site | Indicative RPO | Indicative RTO |
|---|---|---|
| E-commerce | 15 min – 1 h | 1–4 h |
| B2B SaaS | 5–15 min | < 1 h |
| Corporate site | 24 h | 4–24 h |
| Blog | 24 h | 48 h |
RPO of one hour implies hourly backup, plus binlogs if the database allows. RTO of four hours requires documented procedure and restore already tested — not a first attempt under stress on Sunday evening. If nobody has timed a full restore, your stated RTO is a guess.
Minimum architecture and host role
The 3-2-1 rule remains the base: three copies, two media, one off-site. Build full inventory: Git code, database, uploads, DNS records, secrets and certificates. Write a numbered runbook: who calls the host, who switches DNS, who validates restored database — see domain redirects for failover pitfalls.
Prepare recovery environment: cold VPS, ready image, or documented second host. Plan external communication via status page and pre-written incident messaging. The host often provides snapshots; you must export the database, encrypt off-site copy, test restore, and manage secondary DNS failover if stakes justify it.
Testing restore: the only proof that counts
A backup never restored is a promise. Each quarter, run a full exercise: restore to staging, verify uploads, test app connection, measure real duration. Note gaps between measured time and advertised RTO.
Typical failures appear here: backup plugin excluding uploads, snapshot too old, incompatible PHP on recovery server, missing secrets in vault. Fix the process after each exercise — not only the imaginary outage.
Failover, DNS and second host
For critical sites, a second host or pre-configured recovery zone reduces RTO. DNS failover remains the fragile point: high TTL, resolver cache, certificates tied to old server. Document the sequence: lower TTL before planned change, switch A/AAAA, verify HTTPS, rollback if failure.
Cold standby costs less than warm standby but lengthens time to service. Choose based on acceptable RTO and budget — not team ego.
The climax — backup reassures; only restore proves
Decide and move forward without blind spots
Start by setting RTO and RPO per critical service, validated with the business. Then automate off-site backups and keep an inventory of secrets and dependencies. Schedule quarterly restore test and record real observed duration. Compare hosts that document snapshots and procedures via the directory. Consider a second host or recovery zone if financial or reputational stakes exceed redundancy cost.
Frequently asked questions
What is the difference between backup and disaster recovery plan?
Backup copies data. Recovery plan defines who restores what, how fast, acceptable loss, and how to continue if the host is unavailable. Without written, tested procedure, the copy stays theoretical on crisis day.
Are automatic host backups enough?
Not alone. Frequency, retention, and restore are not always contractually guaranteed. Need off-site copy, quarterly test, documented procedure — see hosting terms.
What RTO/RPO for e-commerce?
Indicative: RPO under one hour for orders, RTO under four hours — calibrate on revenue lost per hour. Brochure blog often tolerates 24 hours; blocked checkout during business hours costs far more.
Need a second host?
For critical sites: yes — DNS failover, standby infrastructure, validated runbook. Cost vs risk. On shared hosting, second host not mandatory if long RTO acceptable — but decide explicitly.
A backup you never restored is a promise. A DRP is the promise kept against a stopwatch.