WordPress Backups and Disaster Recovery: The Guide You Read Before You Need It

A WordPress backup is one of those things every site owner believes they have until the morning they actually need one. The host “does backups”. A plugin was installed in 2022. An agency “handles it”. Then the site is hacked, or an update takes the database down, or the hosting account is suspended, and the backup turns out to be six months old, incomplete, stored on the same server that just died, or protected by a password nobody can find. I have been the person called in on that morning many times, and the difference between a bad day and a lost business is almost never luck – it is whether someone treated backups as a recovery plan instead of a checkbox.

This guide is written recovery-first: the disasters that actually happen, what a real backup contains, the 3-2-1 rule applied to WordPress, honest notes on the tools (host backups, UpdraftPlus, BlogVault, JetBackup, WP-CLI), the quarterly restore test that turns hope into certainty, RTO and RPO in plain language, the disaster recovery runbook to write before anything breaks, and specific walk-throughs for broken updates, hacks, dead hosts and WooCommerce stores. I am a freelance WordPress developer with 12+ years and 500+ projects behind me, and a fair share of those projects started as a rescue – so this is the guide I wish my rescue clients had read a year earlier.

Table of contents

• The disasters that actually happen
• What a real backup is: the 3-2-1 rule for WordPress
• What must be in scope – and what you can leave out
• Backup frequency by site type
• The backup toolbox, honestly
• An untested backup is a hope, not a backup
• RTO and RPO in plain language
• The disaster recovery runbook to write before you need it
• Recovery walk-throughs: broken update, hack, dead host
• WooCommerce: backing up a site where orders never stop
• Costs, and a decision table you can act on
• Frequently asked questions

The disasters that actually happen

Backup advice usually starts with the solution. Start with the failure instead, because the failure defines what the backup must survive. These are the six disasters I actually see, roughly in order of frequency:

• A hacked site. Malware injected into theme files, spam pages in the database, a backdoored admin user. You need a clean copy from before the compromise, which might be days or weeks back – so retention matters as much as frequency. I wrote a full step-by-step hacked site recovery guide; a trustworthy backup is the difference between a two-hour restore and a two-day forensic clean-up.
• A botched update. A plugin or core update white-screens the site or silently corrupts data. Common, low-drama, and exactly what a yesterday backup fixes in twenty minutes.
• Host data loss. Rarer, but it happens: disk failures, failed migrations between host data centres, hosts that go out of business. If your only backup lives at the same host, it dies with them.
• Account and billing drama. An expired card, a lapsed domain, a hosting account suspended over a dispute. The site is technically fine – you just cannot reach it, sometimes for weeks. An off-site backup lets you rebuild elsewhere while the paperwork drags.
• Accidental deletion. Someone deletes a page tree, empties the media library “to save space”, or a bulk action goes wrong. You need file-level and database-level restore, not just “roll the whole server back three days” – which would also delete three days of good work.
• The dead developer problem. The freelancer or agency who built the site holds the hosting login, the backups and the domain, and they have stopped answering. No technology failed, yet the business has lost its website. This one is solved by ownership, not software, and I cover it in the runbook section below.

Notice what these have in common: in four of the six cases, a backup stored inside the same hosting account is worthless. That observation leads directly to the rule that should shape your whole strategy.

What a real backup is: the 3-2-1 rule for WordPress

The 3-2-1 rule is old sysadmin wisdom and it maps onto WordPress perfectly: keep 3 copies of your data (the live site plus two backups), on 2 different types of storage, with at least 1 copy off-site – meaning outside your hosting provider’s control entirely.

Run the typical setups through that test and you see why so many “we have backups” sites fail it:

• Host backups only. One copy, same server or same provider, same account. If the disk dies, the provider fails, or the account is suspended, the backup goes down with the site. Same failure domain = not a backup, just a convenience.
• A backup plugin writing to wp-content/backups. Worse than it looks: the backup lives inside the site itself. A hacker who owns the site owns the backups too, and can read your database dumps at leisure. Also, one full-disk event removes everything.
• Host backups plus a plugin sending copies to Google Drive or S3. Now you pass: live site, host copy, off-site copy at an unrelated provider. This is the minimum I set up for every client site, and it costs a few euros a month at most.

The point of 3-2-1 is not paranoia, it is failure-domain thinking. Every copy that shares a login, a provider or a server with the live site can be destroyed by the same event that destroys the live site. You want at least one copy that survives your host disappearing and your admin password being stolen – because both of those things genuinely happen.

What must be in scope – and what you can leave out

A WordPress site is two things, and a real backup captures both:

The database

Posts, pages, orders, users, comments, settings, plugin data – everything that changes daily lives here. A files-only backup that misses the database is a brochure of your site, not your site. Export it as SQL (mysqldump or the equivalent), and make sure the dump includes all tables with your prefix, including plugin tables like form entries and WooCommerce order tables.

The files

• wp-content/uploads – your media library, usually the largest and least replaceable part. Core and plugins can be re-downloaded; your images cannot.
• Your theme – especially if it is custom-built. This is code that exists nowhere else.
• Plugins – technically re-downloadable, but you want the exact versions that worked, plus any premium plugins whose download links you would otherwise chase across old emails.
• wp-config.php – database credentials, salts, custom constants. Restoring without it means reconstructing configuration from memory.
• .htaccess (or nginx config) – redirects, security rules, caching directives. Losing a redirect file after a migration quietly bleeds SEO for months.

What you can safely exclude

Cache directories (wp-content/cache, page-cache folders from LiteSpeed or W3TC), object cache files, image-optimisation duplicates, old backup archives sitting inside the site, and log files. Excluding these often cuts backup size by 30-60% and makes every run faster and cheaper to store. What you must never exclude to save space: uploads and the database – and yes, I have seen both excluded “temporarily”.

Backup frequency by site type

Frequency is not a matter of taste; it equals the amount of work you are willing to lose. Ask “if I restored yesterday’s backup right now, what disappears?” and set frequency so the honest answer does not hurt.

• Brochure site (content changes monthly): weekly full backup, plus an extra manual backup before any content session or update round. Losing six days of a site that changed nothing costs nothing.
• Active blog or news site (content changes daily): daily database backup, weekly full file backup. Files change rarely (uploads aside); the database is where the writing lives.
• Membership or booking site: daily full, and consider twice-daily database dumps – registrations and bookings between backups are real customers.
• WooCommerce store: real-time or hourly database backup. Every order that lands between backups is money and a legal record. If your store takes an order every few minutes, a daily backup means a restore could silently delete a day of paid orders – that is the store’s RPO problem, and I cover it properly in the WooCommerce section.

Two universal additions regardless of type: take a manual backup before every update round – it is the cheapest insurance in WordPress – and keep enough retention. Thirty days of daily backups is a sensible default; a hack discovered after three weeks is common, and seven days of retention leaves you with seven infected copies. The update-day backup habit belongs in your routine alongside everything else in my WordPress maintenance checklist – that post covers the ongoing routine; this one is about the strategy behind it.

The backup toolbox, honestly

There are four tool classes, and most sites should combine two of them. Here is the honest version of each.

Host backups: fine as one copy, never as the only copy

Most decent hosts run nightly snapshots, and managed WordPress hosts (Kinsta, WP Engine, Cloudways and similar) do it well with one-click restores. Use them – they are the fastest restore path for the everyday “bad update” case. But check three things in your host panel today: how many days of retention you actually get (I have seen “backups included” mean three days), whether you can download a backup out of the panel, and whether backups survive account suspension (usually they do not). Host backups are your convenient copy, not your off-site copy – same provider, same account, same failure domain.

Plugin-based: UpdraftPlus and friends

A backup plugin running inside WordPress, pushing archives to remote storage. UpdraftPlus is the one I install most: the free version schedules database and file backups to Google Drive, Dropbox or Amazon S3, and restores from inside wp-admin. The premium version (about USD 70/year) adds incremental backups, more destinations and migration tools. Comparable options: BackWPup, Duplicator, WPvivid. Strengths: cheap, off-site by design, you own the storage. Honest weaknesses: it runs inside WordPress, so a fully broken or compromised site cannot run its own restore (you restore by unpacking archives manually instead – workable, slower); and large sites can hit PHP timeouts during backup runs, so verify the archives actually complete rather than trusting the green tick.

Managed backup services: BlogVault, Jetpack VaultPress

These run the backup from their own servers, store it on their infrastructure, and offer one-click restore that works even when your site is completely down – which is precisely when you need it. BlogVault (from around USD 149/year per site) does incremental real-time backups, staging, and restores to any host; Jetpack VaultPress Backup (around USD 120/year) does real-time backups with an activity log so you can restore to the moment before a specific change. You are paying for the restore experience and for someone else guaranteeing the copies exist. For WooCommerce stores and for owners who will honestly never test a plugin backup, this category is worth every euro. Trade-off: recurring cost per site, and your data sits with another third party – check where, if compliance matters to you.

Server-level and developer tooling: cPanel, JetBackup, WP-CLI

On cPanel hosting, JetBackup (if your host includes it) gives file- and database-level restores with decent retention – find out whether yours has it. For developers and anyone comfortable with SSH, a WP-CLI script on a cron job is the most transparent backup that exists – you can read every line of what it does:

#!/bin/bash
# nightly-backup.sh - cron: 17 2 * * *
SITE=/var/www/example.com
STAMP=$(date +%F)
wp db export /backups/db-$STAMP.sql --path=$SITE --add-drop-table
tar -czf /backups/files-$STAMP.tar.gz -C $SITE \
  wp-content/uploads wp-content/themes wp-content/plugins \
  wp-config.php .htaccess
rclone copy /backups b2:example-backups/   # off-site, separate account
find /backups -type f -mtime +30 -delete   # keep 30 days locally

Storage for the off-site copy is nearly free: Backblaze B2 at USD 6/TB/month or Amazon S3 with lifecycle rules; a typical business site’s 30-day archive set costs well under EUR 1/month.

Whatever you choose: protect the backup storage itself

Your backup archive contains your entire database – every user, every customer, every password hash – so backup storage credentials are keys to everything. Three rules I apply on every setup: store backups in a separate account (a dedicated Google account or cloud-storage account, not the same login that runs the site or the email); give the site write-only or limited credentials where the storage supports it (S3 and B2 application keys can be scoped so the site can add backups but not delete or read old ones); and turn on versioning or object-lock immutability on the bucket. That last one matters against the ransomware pattern: an attacker who gains access does not just encrypt your site, they overwrite or delete your backups first. Immutable versions mean even a deleted backup can be recovered. Encrypt archives at rest (UpdraftPlus premium and the managed services do this; for scripts, rclone’s crypt remote works), and store the encryption key somewhere that survives the site – a password manager, not wp-config.

An untested backup is a hope, not a backup

Here is the core message of this whole guide: a backup you have never restored is a hope, not a backup. In rescue work I regularly meet backups that ran faithfully for two years and turn out to be empty archives, database-only dumps, files from a staging copy, or encrypted with a key nobody kept. Every one of those failures would have been discovered by a single test restore – calmly, on a Tuesday, instead of during the outage.

So schedule a quarterly restore test. It takes 30-60 minutes and it is the highest-value hour in site maintenance:

1. Create a staging environment. Your host’s one-click staging, a subdomain like restore-test.yoursite.com, or a local environment (LocalWP) – anywhere that is not the live site.
2. Take your most recent real backup – the actual scheduled one from your off-site storage, not a fresh manual export. You are testing the pipeline, not your ability to copy files today.
3. Restore it completely: import the database, unpack the files, fix the URLs (wp search-replace, or the plugin’s migration handling), point a hosts-file entry or staging domain at it.
4. Verify like a user, not like a developer: the site loads without errors on several pages; wp-admin login works with a current password; the media library shows images (missing uploads are the most common gap); a contact form submits and the entry is recorded; on a store, recent orders are present and a test checkout completes; menus, redirects and the theme all behave.
5. Time it and write it down. How long from “start” to “verified working”? That number is your real recovery time, and you will want it for the runbook. Note anything that surprised you and fix the pipeline now.

Put the test in the calendar with the rest of your quarterly tasks. Fifteen minutes for a small site once you have done it twice, and it converts your backup system from “probably fine” to “restored successfully on 14 June, took 40 minutes”. Those are very different sentences to say to yourself during a disaster.

RTO and RPO in plain language

Two pieces of jargon are worth learning because they turn vague anxiety into two concrete decisions. RPO (recovery point objective): how much recent work can you afford to lose? That sets backup frequency. RTO (recovery time objective): how long can the site be down? That sets which restore method you need. Realistic numbers, from doing this many times:

Match the numbers to the business, not to the technology. A brochure site can live with a 24-hour RPO and a half-day RTO – weekly plugin backups and host snapshots are genuinely enough, and paying for real-time backup there is overkill I will talk you out of. A store doing EUR 2,000 a day cannot accept losing a day of orders or being down for one: it needs real-time database backup and a rehearsed sub-hour restore. Decide the two numbers first; the tool choice falls out of them.

The disaster recovery runbook to write before you need it

When a site is down, the owner is stressed, the developer (if reachable) is guessing, and every “where is the…?” question adds an hour. A disaster recovery runbook is one document, written on a calm day, that answers those questions in advance. Yours needs six sections and fits on two pages:

1. Where the backups live. Exact locations (host panel path, S3 bucket name, BlogVault account), which email owns each account, and where the credentials are (a shared password manager entry, not “Ravi knows it”).
2. How to restore, step by step. The commands or clicks, written down from your last successful restore test – not from memory, not from the plugin’s marketing page.
3. Access map. Registrar login (who controls the domain), DNS provider, hosting account, wp-admin, FTP/SSH, email provider. Half of every slow recovery is spent recovering access, not data.
4. Who to call. Your developer (me, for my clients), the host’s support channel and expected response time, and who in the business can approve decisions at 9pm.
5. Decision rules, agreed in advance. For example: “If the live site is not fixed within 2 hours, restore yesterday’s backup and accept the data loss.” “If hacked, take the site offline immediately, restore to a clean environment, do not just patch and hope.” Deciding thresholds during a crisis produces either panic-restores or endless dithering; deciding them in advance produces action.
6. The restore-test log. Date, backup used, time taken, result. Proof the plan works.

Then the rule that makes it all usable: keep a copy of the runbook outside the site and outside the hosting account. A PDF in two inboxes and a printed copy in a drawer beats a beautiful wiki page hosted on the server that is currently down.

Ownership: the questions business owners should ask today

If an agency or freelancer built and maintains your site, the dead-developer disaster is prevented by asking, politely and in writing: Where exactly are the backups stored, and can I see the storage? Do I have my own login to the hosting account and the domain registrar (owner-level, not “we manage it for you”)? If our relationship ended tomorrow, what would I hold in my own hands? A professional answers happily – I set every client up so the hosting, domain and backup storage are in accounts the client owns, with me as a collaborator. If the answer is defensive or vague, that is your disaster warning, delivered early enough to act on. Any handover should include: all credentials via a password manager, the backup locations, the runbook, and a demonstration restore.

Recovery walk-throughs: broken update, hack, dead host

Case 1: an update broke the site

Yesterday’s site was fine, today’s plugin update white-screened it. First decide what to roll back: if the failure is code (fatal error, broken layout), restore files only – or even just the offending plugin’s folder – and keep today’s database, so you lose no content or orders. If the update also migrated the database schema (major WooCommerce or core updates sometimes do), you may need both files and database from before the update – which is exactly why the pre-update manual backup exists. Restore, confirm the site works, then retry the update on staging to find out what actually went wrong before it goes near production again.

Case 2: the site is hacked

Restoring a backup is step one of recovery, not the whole recovery. Restore a copy from before the compromise (check file modification dates and your security scanner’s first alert to pick the date), then immediately patch the entry point – update everything, rotate every password and salt, remove unknown admin users – or you are restoring a clean site with the same open door. The full sequence, including how to find the entry point, is in my hacked WordPress recovery guide, and the prevention side is in common WordPress security mistakes. This case is also the argument for 30+ days of retention: hacks are often discovered late, and you need a copy that predates the infection.

Case 3: the host is gone

Host bankruptcy, account suspension, a data-centre failure with no ETA – the site must move, now. This is the scenario only an off-site backup survives. The sequence: sign up with a new host, restore files and database there, update wp-config with the new database credentials, test via a hosts-file entry pointing your domain at the new server, then switch DNS. If your DNS was hosted at the dead host, you will be very glad your runbook lists the registrar login, because you can repoint nameservers from the registrar directly. Drop DNS TTL to 300 seconds before the switch if you can. Done carefully this preserves your search rankings too – the same rules as in my guide to migrating a website without losing SEO – and if you would rather not do it under pressure, an emergency move is a routine job within my WordPress migration service.

WooCommerce: backing up a site where orders never stop

A store breaks the normal backup logic in one specific way: the database changes every few minutes, and each change is money. Three consequences follow.

First, frequency: real-time or hourly database backup is not a luxury. With nightly backups, a restore at 6pm deletes every order placed since 2am – customers have paid for products you now have no record of selling. A real-time service (BlogVault WooCommerce plans, Jetpack VaultPress) records each order as it happens; a cheaper compromise is hourly WP-CLI database dumps, shrinking the exposure to minutes-to-an-hour of orders.

Second, the merge problem. Suppose the store was hacked on Monday and you discover it Thursday: the clean backup is from Sunday, but Monday-Thursday contains real orders inside a compromised database. You cannot just restore Sunday – that deletes paying customers. The practical approach: restore Sunday’s copy to a clean environment, then export the missing orders from the infected database (WooCommerce’s order export, or careful SQL against the order tables) and import them into the clean site, checking them by eye – order data is structured enough for this to be tedious but safe, unlike merging arbitrary content. This is fiddly, careful work; it is exactly the kind of job I do inside my WooCommerce development service, and the existence of the merge problem is the strongest argument for real-time backup, which avoids it entirely.

Third, restore hygiene: put the store in maintenance mode during any restore. An order placed mid-restore lands in a database that is about to be overwritten – the customer pays, the record vanishes. Enable maintenance mode (or hold traffic at the host level), restore, verify orders and stock levels, test one checkout, then reopen. Also confirm your backup scope includes the WooCommerce tables beyond wp_posts – modern WooCommerce stores orders in its own wc_orders tables (HPOS), and a backup tool configured years ago with a table whitelist can miss them.

Costs, and a decision table you can act on

The honest arithmetic first. A serious backup setup costs, per site per year: EUR 0-70 for a plugin plus a few euros of cloud storage, or EUR 110-250 for a managed real-time service. One incident on the other side of the ledger: a store turning over EUR 1,500 a day that is down for five days while someone rebuilds from fragments has lost EUR 7,500 of revenue, plus recovery fees, plus the customers who bought elsewhere and the refund chaos from orders that vanished. Even my modest rate of EUR 15/hour turns a from-scratch forensic rebuild into hundreds of euros, against a backup bill of under one euro a week. I recommend against overkill everywhere on this site – real-time backup for a brochure site is wasted money – but nobody has ever told me they regretted the size of their backup bill during a restore.

Whatever row you sit in, the sequence to act on is the same: this week, confirm what your host actually keeps and add one off-site copy; this month, write the two-page runbook and store it outside the site; this quarter, run the first restore test. After that it is maintenance, not a project.

Want your backups handled – and actually tested?

Backup strategy, off-site copies, the quarterly restore test and the runbook are all part of my WordPress maintenance and security service – flat monthly plans, and every plan includes restores that are rehearsed, not hoped for. You can see the kind of sites I look after in my portfolio. If you want a second opinion on your current setup – or you are reading this on the bad morning itself – send me a message; I reply within 24 hours, and faster when a site is down.

Frequently asked questions

What is the best WordPress backup strategy?

Follow the 3-2-1 rule: the live site plus two backup copies, with at least one stored off-site away from your hosting provider – for example host snapshots plus a plugin or managed service sending copies to S3 or Google Drive – and test a restore quarterly.

Are my hosting provider’s backups enough?

No – they are one useful copy, not a strategy. They share a failure domain with your site: a provider failure, disk loss or account suspension takes the backups down with the site, and retention is often only a few days.

How often should I back up a WordPress site?

Match frequency to how much work you can afford to lose: weekly for brochure sites, daily for blogs and business sites, real-time or hourly database backups for WooCommerce stores – plus a manual backup before every update round.

How do I test a WordPress backup?

Restore your most recent scheduled backup to a staging environment, then verify like a user: pages load, admin login works, media displays, forms submit and recent orders exist. Time it and log the result quarterly.

What are RTO and RPO for a WordPress site?

RPO is how much recent data you can afford to lose (it sets backup frequency); RTO is how long you can afford to be down (it sets your restore method). Decide both numbers first and choose tools to match.

Can I recover a hacked WordPress site from a backup?

Yes, if you have a clean copy from before the compromise – which is why 30+ days of retention matters. Restoring is only half the job: you must also close the entry point, or the hack returns.

How do I restore a WooCommerce store without losing orders?

Use real-time database backups so the restore point is minutes old, put the store in maintenance mode during the restore, and if orders were placed after the backup point, export them from the old database and import them into the restored site.