What counts as a disaster for a WordPress site
Most WordPress disasters are not dramatic. A plugin update corrupts data, an admin account is compromised, a host suspends the account, a database table is dropped by mistake, a migration fails halfway. Each one takes away something different: the files, the database, access to the hosting account, or control of the domain. Planning around what you can lose is more useful than planning around the event.
Set two numbers first
NIST's contingency planning guide (SP 800-34 Rev. 1) defines the recovery point objective as the point in time to which data must be recovered after an outage. It defines the recovery time objective as how long a system's components can be in the recovery phase before the organization's mission suffers. In plain terms, RPO is how old the restored data can be, and RTO is how long the site can be gone.
Your backup schedule sets your RPO. A database backup taken at 3 a.m. and restored at noon loses every order, form entry and comment from the nine hours in between. The WordPress handbook suggests weekly backups for smaller sites and daily backups for busy ones. Treat that as a starting point. If the site takes orders or intake requests, work out what nine hours of lost submissions would cost and set the schedule from that number.
Your restore process sets your RTO, and most teams only learn theirs during an outage. Write both numbers down, along with the name of the person who can approve a restore.
What goes in the recovery set
WordPress keeps its content in two places. The files (core, themes, plugins, uploads and wp-config.php) sit in the site directory. The database (posts, pages, settings and comments) lives in MySQL or MariaDB, outside that directory. The WordPress handbook is explicit that backing up the files does not back up the database, and that a typical site needs both to be restored.
Treat the two as one set, taken around the same time. The handbook's suggested order is to back up the database first and then the files, and to restore the files first and then import the database. If the database credentials changed, update wp-config.php to match.
From the command line, WP-CLI can export the database using the credentials already in wp-config.php:
wp db export before-update.sql
Under the hood that runs mysqldump, so the standard commands from the handbook work as well. To restore a dump:
mysql -h DB_HOST -u DB_USER -p DB_NAME < backup.sql
Several things a restore depends on live outside the WordPress directory, so a file-and-database backup does not include them:
- Domain registrar access and the current DNS records.
- The hosting account login, and who owns that account.
- CDN or firewall settings, if the site sits behind one.
- Outgoing email setup (SMTP or email-service credentials), because forms depend on it.
- Plugin and theme license keys, which premium plugins may need to update or reactivate.
- Keys for third-party services such as payment gateways and CRMs.
Keep these in a password manager that more than one person can open.
Keep one copy out of reach
CISA's #StopRansomware Guide recommends maintaining offline, encrypted backups of critical data and regularly testing their availability and integrity in a disaster recovery scenario. Its reasoning is that many ransomware variants look for accessible backups and delete or encrypt them. The same logic applies to a compromised WordPress site: a backup stored on the same server, or in an account the site can write to and delete from, is only as safe as the site.
The WordPress handbook recommends keeping at least three to five recent backups in different places, for example on the host, in cloud storage and on a local computer. Two checks are worth making on your own setup. First, find out where your backup tool keeps the credentials it uses to reach remote storage, and what that account is allowed to delete. Second, make sure at least one copy cannot be modified by anything connected to the live site.
A clean copy also has to predate the problem. If the cause was a compromise, restoring before you have found and closed the entry point just gets the site reinfected. The order of steps is covered in My WordPress Site Was Hacked: What to Do First.
Test a restore, and time it
The CISA guidance and the WordPress handbook both say to test backups. The handbook suggests manually checking automatic backups now and then to confirm the process works. A restore test is also the only way to learn your real RTO. Run it on a copy, never on the live site.
- Pick a restore point and note its date and time. Start a stopwatch.
- Set up an empty test environment with its own database and its own address. Do not point it at the live database.
- Restore the files, import the database, then update wp-config.php with the test database's credentials.
- Adjust anything that ties the copy to the live address. If the test copy uses a different domain, the site URLs stored in the database will need attention.
- Check what the site is for: log in, submit a form and confirm the email arrives, run a test checkout if you sell online, and load the main pages on a phone.
- Stop the clock. Record the total, plus every step that needed a password nobody had or help from someone who was not available.
Compare that total with your RTO. If they do not match, change the plan or the target before an outage forces the question.
Write a one-page runbook
Recovery under pressure goes better from a page than from memory. The page should cover who decides to restore and who is allowed to; where each backup lives and who holds its credentials; the restore order above; the contacts at your host, registrar and developer; and how and when you tell customers or staff the site is down. Review it whenever the hosting, the plugins or the people change. For the update side of this, see Why WordPress Updates Need a Process, Not Just a Click.
If your host's backup is the only backup
The WordPress handbook notes that most hosts back up the entire server, but that requesting a copy from them takes time, and a speedy recovery is the whole point. Ask your host how you request a restore, how long it usually takes, how far back it can go, whether it restores the database as well as the files, and who on your account is allowed to trigger it. If the answers are vague, treat the host's backup as a second copy, not as the plan.
Where managed operations fit
The Managed WordPress page lists daily automatic backups and one-click restore as part of the hosting, and the pricing page lists multiple backup points under Managed Stability and the maintenance plan. Whatever you use, ask the same questions: how many restore points, how far back they go, where they are stored, who can delete them, and when a restore was last tested.
For how backups, recovery and monitoring fit into running a site the business depends on, see Is WordPress Reliable Enough for a Mission-Critical Website? If a plugin update is what broke the site, start with how to roll back a plugin update safely. If the site is down right now, our emergency support can help.
