Disaster Recovery for WordPress: RTO, RPO and a Runbook

The host went down at 14:05 on a Thursday. The site was back at 19:40. The restore itself took fifty minutes. The other four and a half hours went to finding out whether the host was coming back, finding the last backup, finding out who could approve the spend on a new server, and finding the person who had the registrar password. The technical recovery was not the disaster. The absence of a plan was.

Disaster recovery is the part of backup work that happens before the incident: deciding which failures the site must survive, how quickly, with how much data loss, and who is allowed to press the button. The backup is one input. The rest is a decision table, a one-page runbook and a rehearsal.

The vocabulary is worth fixing early because it drives the budget. Recovery time objective, RTO, is the longest the site can be down. Recovery point objective, RPO, is the most data the business can lose. A store that takes orders all day might have an RTO of one hour and an RPO of five minutes. A brochure site might have an RTO of two days and an RPO of a week. Neither number is technical. Both decide what you build.

Disclosure: some links on this page are affiliate links, and WPSifero may earn a commission if you buy through them. The targets and the runbook come first; the products named at the end are ways to meet them, not the plan itself.

Disaster recovery is a decision table, not a backup

A backup answers one question: can the site be rebuilt? Disaster recovery answers a larger set: which failures are in scope, who declares an incident, what gets restored first, how customers are told, and when the old environment is abandoned. A site with excellent backups and no decision table still spends the first hours of an outage arguing.

The table starts with the cost of downtime. For a store, that is revenue per hour plus the support load plus the reputation cost of a checkout that fails on a Saturday. For a publication, it is traffic and the trust of readers who arrive at an error page. For an internal tool, it is the number of people standing idle. Put a number on it, even a rough one, because every later decision is a comparison against it.

Then the targets. RTO is a promise about time; RPO is a promise about data. Write them as sentences with an owner: "The store is accepting orders again within two hours of a declared incident, losing no more than fifteen minutes of orders, and the person who declares it is the on-call engineer." A target without an owner is a wish.

Name the five disasters and rank them by likelihood

Most recovery plans are written for the rare dramatic failure and never used for the common one. Rank the scenarios by what has actually happened to sites like this one, then by impact. The table below is a starting point, not a universal ranking.

Each row has a different first action, which is why a single "restore the backup" plan fails. A compromise is not fixed by restoring the newest backup. A DNS loss is not fixed by restoring anything. A host outage may not need a restore at all if the data is intact and a standby exists.

The ranking also tells you where to spend. If the most likely failure is a bad update, the highest-value control is a fast rollback, not a second data centre. If the most likely failure is an account suspension, the highest-value control is a payment method that does not expire and a backup that is not in the account.

The runbook is one page with names and numbers

The runbook is not a policy document. It is a page somebody can open at two in the morning and follow. It has four parts: how to declare an incident, who does what, where the credentials are, and the steps for each scenario. Keep it outside the site, because the site is the thing that may be unavailable.

INCIDENT RUNBOOK — example.com
Owner:      Name, phone, backup phone
Declare:    Any of: site down 5 min, checkout failing, warning page,
            unknown admin account, host status incident.
Channels:   #ops (internal), status.example.com (public)

Credentials: password manager folder "example.com / DR"
Backups:     bucket name, region, key location, retention
DNS:         registrar, account, TTL, zone file location
Hosting:     provider, account, support PIN, standby target

Steps per scenario:
  1. Confirm scope (site only, account, DNS, provider)
  2. Announce in #ops with time and scenario
  3. Follow the scenario card in the DR folder
  4. Update status page every 30 minutes
  5. Declare recovery, then write the timeline

The names matter more than the steps. During an incident, the common delay is not the command; it is finding out who can approve a new server, who holds the registrar login, and who is allowed to tell customers. Write those three names down and keep them current. A runbook with a departed employee's phone number is worse than no runbook, because it looks ready.

The scenario cards can be short. For a host outage: confirm from outside, check the status page, decide between waiting and failing over, lower DNS TTL if not already low, bring up the standby, switch DNS, verify checkout, tell customers. For a compromise: preserve, contain, rebuild, then the blocklist steps. Each card fits on half a page.

DNS is the failover mechanism you already have

Most WordPress sites do not need a load balancer or a second data centre. They need DNS that can be pointed somewhere else quickly, and a copy of the site waiting at the other end. The mechanism is already in place; the mistake is leaving it with a one-hour TTL and a registrar login that nobody can find.

Lower the TTL on the records that matter to five minutes, and do it before an incident, because a TTL reduction takes effect only after the old value expires. Keep the zone file exported and stored with the runbook. Use a DNS provider that is separate from the hosting provider, so a hosting failure does not take the control plane with it. Keep the registrar account with two-factor authentication and a payment method that does not expire.

Mail is the part people forget. Moving the web records without moving or preserving MX, SPF, DKIM and DMARC takes the website up and email down. A restore that brings back the site and loses the mailbox is not a recovery. Keep the mail provider independent of the web host where possible, so a web outage does not stop password resets and customer replies.

Warm standby, cold standby, or restore from backup

The standby strategy is a cost decision. A cold standby is a backup plus a documented way to build a server. A warm standby is a running copy with the database replicated or regularly refreshed, ready to take traffic after a DNS switch. A hot standby is a second environment serving traffic continuously, which is beyond what most WordPress sites need.

The warm standby is the sweet spot for most stores. It does not need the same capacity, only enough to serve until the main environment returns, and it needs a current database. Keeping it current is the hard part: a nightly copy means an RPO of a day, which may be too much for orders. Replicating the database or shipping binlogs is more work and narrows the gap.

Do not build a standby you cannot activate. A second environment with stale credentials, an expired TLS certificate and a plugin licence tied to the old domain is not a standby. It is a second site that will fail in a different way. Activate it quarterly, run a checkout, and then switch back.

Rehearse the decision, not only the restore

The restore drill proves the backup works. The tabletop exercise proves the plan works. Once a quarter, gather the people who would be involved, pick a scenario, and walk through it with a clock. No systems are changed. The output is a timeline and a list of questions nobody could answer.

Run it as a story. "The host is unreachable and its status page says nothing. It is 09:00 on a Monday. Go." The first ten minutes reveal whether anyone knows how to confirm the outage from outside, who calls the host, and whether the DNS login is where the runbook says it is. The next twenty reveal whether the standby can actually serve the site. The last ten are for the communication: who writes the status update, what it says, and who approves it.

The exercise is uncomfortable in a useful way. Every unanswered question is a gap that costs minutes during a real incident. Fix the runbook, not the people. Then repeat with a different scenario next quarter, because the plan that works for a host outage may fail for a compromise.

The one page to write this week

Write the RTO and RPO as sentences with an owner. Rank the five scenarios. Name the incident commander, the backup, and the person who approves spending. Put the credentials path, bucket name, DNS provider and registrar in one place outside the site. Write a card for each scenario. Lower the TTL and export the zone. Book the tabletop exercise.

Then choose the tooling that meets the targets rather than the tooling that looks most complete. Jetpack's backup service provides off-account restore points, which covers the cold-standby end of the table. Pressable provides a managed environment with staging and infrastructure handled, which is a reasonable warm-standby host for a store that does not want to run the second environment itself.

Where the heavier plan is the wrong purchase: a brochure site with ten pages, no logins and no transactions. There, an off-host weekly backup, a five-minute TTL and a one-page runbook are proportionate, and a standby environment is money spent on a risk that costs a day of inconvenience. The decision rule is the comparison the whole article is about: the annual cost of the plan against the hourly cost of downtime multiplied by the hours the plan removes. If the plan costs more than the outage it prevents, it is not insurance. It is decoration with a contract.