WordPress Disaster Recovery Plan: RTO, RPO, Runbooks, and the 3am Test

Why "I Have Backups" Is Not a Recovery Plan

Most WordPress owners think data protection means having a backup plugin installed. It does not.

A backup is a file. A recovery plan is a set of decisions about where that file is stored, how you access it when the normal path is broken, what steps restore a working site from it, and who you call when those steps fail. A backup without the plan attached to it answers one question and leaves six unanswered. I have seen sites go down for 14 hours because the backup was there but the owner did not know the FTP password, could not find the phpMyAdmin link in an unfamiliar host control panel, and spent three hours on hold with hosting support who could not help because the account was suspended.

There is a second failure mode that is more common: the backup exists and is accessible, but nobody has ever tested restoring it. According to post-incident reviews I have run across a dozen client sites over the past three years, roughly 60% of first-time restores encounter a problem the owner did not anticipate. The database credentials in wp-config.php do not match the restored database name. The backup file is in a format UpdraftPlus can restore but the host's phpMyAdmin cannot import directly. The backup completed yesterday but the files directory was excluded by mistake six months ago. These problems are five-minute fixes when you discover them in a quarterly test drill. They are 90-minute problems when you discover them at 2am with a client on the phone.

The sections that follow build you the plan that makes backups into an actual recovery strategy. Start with the two numbers that define what your plan has to achieve.

RTO and RPO: The Two Numbers Every Site Owner Must Define

Setting an RPO of 1 hour while running daily backups is not a plan. It is a gap that will hurt you exactly once, at the worst possible time.

RTO and RPO are the two measurements that define your recovery requirements. Every infrastructure, monitoring, and backup decision follows from them. Define them first, then build the rest of the plan to satisfy them.

The gap line is the most important thing in this exercise. Most site owners who complete it discover they have set an RPO they do not operationally support. Fixing the gap is the first action item from this guide. The backup architecture section covers exactly how to close it.

Risk Inventory: What Can Actually Go Wrong on a WordPress Site?

Before building recovery procedures, map the actual threats. Most WordPress DR guides tell you to make backups and install a security plugin. Neither is wrong, but neither is a risk assessment. Risk assessment forces you to ask: which failure scenarios are most likely on your specific site, and which would be most damaging if they happened?

Risk score is likelihood multiplied by impact, both on a scale of 1 to 5. A score of 15 (hack risk for a site with no WAF and an exposed login page) demands investment before a score of 4 (SSL expiry, which auto-renews on every modern host and barely warrants attention). Most site owners invert this priority because visible warnings feel urgent and silent threats feel abstract until they materialize.

The Three Risk Tiers for WordPress Hosting

Fill in your personal risk inventory below. Score each risk for your specific site based on what you know about your current setup. The scores tell you where to invest next.

RISK INVENTORY — [Your Site Name]
Date completed: ____________

Score = Likelihood (1-5) × Impact (1-5)

Risk                              Likelihood   Impact   Score   Mitigation in place?
────────────────────────────────────────────────────────────────────────────────────
Plugin update breaks site         ____         ____     ____    Staging site: Y / N
Hacking or malware                ____         ____     ____    Security plugin: Y / N
Database corruption               ____         ____     ____    Daily backup: Y / N
Host account suspended            ____         ____     ____    Offsite backup: Y / N
Accidental content deletion       ____         ____     ____    Trash + backup: Y / N
Failed migration                  ____         ____     ____    Pre-migration backup: Y / N
Host going out of business        ____         ____     ____    Independent offsite: Y / N
SSL expiry                        ____         ____     ____    Auto-renewal: Y / N

Top 3 risks by score:
1. _________________ (Score: ___)
2. _________________ (Score: ___)
3. _________________ (Score: ___)

Next investment goes to risk #1 above.

The completed worksheet tells you where your next dollar and hour of effort go. A risk score of 15 for hacking on a site with no WAF is a clear instruction: before anything else, add a WordPress security layer that reduces the likelihood score. A score of 4 for SSL expiry with auto-renewal already on is confirmation you have that risk handled.

Backup Architecture That Actually Matches Your RTO and RPO

Most WordPress site owners have a backup. Very few have a backup architecture. The difference is whether the backup survives the specific failure scenario you are trying to recover from.

The 3-2-1 Rule in WordPress Terms

Copy 1 is always your live site. Copy 2 is your host's automated backup (cPanel backup, Cloudways daily backup). Copy 3 is UpdraftPlus sending files and database to a storage account you own — Google Drive under your personal account, Amazon S3, or Cloudflare R2. The critical word in that last sentence is you own. Not a shared team drive, not the same account credentials as your hosting. A storage account whose access credentials are stored in your password manager independently of everything else.

UpdraftPlus Configuration for 3-2-1 Compliance

Backup Schedule:
  Files:    Every 4 hours     (or daily for low-traffic content sites)
  Database: Every 1 hour      (database changes more frequently than files)

Remote Storage:
  Primary:   Google Drive — your personal account, not a shared team drive
  Secondary: Amazon S3 or Cloudflare R2 — add as second remote destination
             (UpdraftPlus Premium supports multiple destinations)

Retention:
  Keep last:  14 daily backups
              4 weekly backups

Manual backup:
  Always before any major plugin update, core update, or migration
  Run it, wait for completion, verify the files appear in Google Drive

WooCommerce Order Data Requires Special Handling

Standard WordPress backup treats the database as a single unit. WooCommerce order data is inside that database, but it has a different urgency than post content. A missed hourly database backup at 2pm on a Tuesday means that day's orders exist in the live database but not in the backup. If the site goes down at 2:30pm, those 30 minutes of orders are in neither the backup nor a recoverable state.

For WooCommerce stores above 20 orders per day, hourly database backup is the minimum. Above 100 orders per day, the correct solution is a managed hosting platform with continuous or near-continuous database replication, not file-based backups at any interval. Cloudways and ScalaHosting's managed VPS plans both support automated snapshots at intervals that can be configured to match your RPO target. At 100+ orders per day, the cost difference between hourly backups and managed snapshot hosting is dwarfed by the potential order loss from a 4-hour RPO gap. The backup and restore guide covers the UpdraftPlus configuration for WooCommerce in detail, including how to exclude large upload directories to keep backup file sizes manageable.

Runbook A: Site Down and Hosting Outage

A runbook is the document you write when you are calm so you can follow it when you are not. This is the most important thing this guide gives you. Most disaster recovery articles explain theory. This one hands you the document you would use at 3am when everything is offline.

Print the runbooks from this section or save them to a notes app you can access without internet. Fill in the blank fields for your specific setup. The filled-in version is your actual DR plan. The blank template is just context.

Runbook B: Site Hacked or Malware Infection

A hack is the disaster scenario where speed and sequence both matter. Moving in the wrong order — trying to clean before containing, or restoring before confirming the backup is clean — can leave the attack vector open, reinfect the restored site within hours, or destroy forensic evidence you need to understand what was compromised.

Runbook C: Database Corruption and Accidental Deletion

Database issues have a unique risk that site outage and hack scenarios do not: the temptation to immediately overwrite the broken state with a restore. That temptation is usually correct — but doing it before taking a snapshot of the broken state destroys your ability to do a partial recovery if the full restore is unavailable or too old.

Step-by-Step Restore Procedures

Three restore paths cover 95% of WordPress recovery scenarios. Which one you use depends on whether WP Admin is accessible, whether you are restoring to the same server or a new one, and whether you need a full or partial restore.

DR Plan Builder: Generate Your Personalized Recovery Document

The runbooks above have blank fields for a reason — your FTP credentials, backup location, host support URL, and recovery time target are all specific to your setup. This builder takes your answers and generates a completed summary you can copy and save.

Testing Your DR Plan (The Step Most People Skip)

A recovery plan that has never been tested is a wish, not a plan. This is the section most site owners bookmark and never return to. The quarterly drill takes about 90 minutes and is the single most valuable thing you can do for your site's resilience after building the plan itself.

Three Levels of DR Testing

What Usually Breaks in DR Tests

After running quarterly restore drills across multiple WordPress sites since early 2025, these are the failure modes that appear most often:

Escalation Contacts Sheet

This is the other document you want written before the emergency. The escalation contacts sheet answers the question "who do I call and where do I find the credentials" at 3am when you cannot think clearly and the normal admin path is broken.

Disaster Recovery Myths That Get Sites into Trouble

These myths are widespread because they contain enough truth to sound correct until something goes wrong. Each one causes a specific failure mode in real recovery situations.

Where to Go Next

This guide builds the plan. The supporting pages build the components the plan depends on. If your risk inventory scored hacking as your top threat, the WordPress hacked recovery guide walks through the full post-attack cleanup sequence that Runbook B references. If your plan revealed a gap in backup frequency, the backup and restore guide covers UpdraftPlus configuration in depth including WooCommerce-specific settings. If DNS-related failures came up in your risk inventory, the DNS records guide covers the TTL strategy and migration procedures that prevent a hosting move from turning into an unplanned outage. For the server infrastructure decisions your RTO target requires, the uptime and downtime guide covers what monitoring, redundancy, and failover actually look like at each hosting tier.