WordPress backup strategies that actually save you

Almost everyone we get an emergency call from has backups. That is the cruel part. The site is down, the database is corrupt, the host restored something from three weeks ago, and the client is forwarding us a folder full of backup files that do not restore. A backup you have never restored is not a backup. It is a hope. This post is about the difference, written from the side of the phone that rings when the hope runs out.

We restore WordPress sites for a living, so we see backup strategies at their worst moment: the one time they get used. The plugins and the 3-2-1 rule you have read about a hundred times are fine. What nobody tells you is which of those backups quietly fail, and how to know yours is not one of them before you need it.

The only test that counts is a real restore

A green checkmark in a backup plugin means the job ran. It does not mean the result will rebuild your site. We have opened backup archives that were missing the database, archives that stopped halfway because the job timed out on a big media library, and archives full of files but zero rows of actual content. The plugin reported success every time.

So the single most useful thing you can do is restore a backup to a throwaway location and see if your site comes back. Spin up a staging site, a local Docker environment, even a cheap subdomain, and actually rebuild from your latest backup once a quarter. If it restores clean, you have a real backup. If it does not, you just found out on a Tuesday afternoon instead of during an outage. We run this test on every client we manage, and it catches a broken backup chain more often than anyone expects.

Your host’s backup is not your backup

Most hosting plans include “daily backups,” and people treat that as the whole strategy. Two problems. First, those backups usually live on the same infrastructure as your site, sometimes the same disk, so the failure that takes down your server can take the backup with it. Second, the retention is short and the restore is on the host’s terms. We have watched a host restore a client to a four-day-old snapshot because that was the oldest one they kept, wiping out four days of orders in the process.

Use the host backup as your fast undo button for small mistakes. Do not let it be your only copy. If the only place your backup exists is inside your hosting account, a compromised account or a billing dispute can take both the site and its backups at once.

The 3-2-1 rule without the lecture

You have seen 3-2-1 before, so here it is in plain terms: keep three copies of your site, on two different kinds of storage, with one of them somewhere else entirely. For a normal WordPress site that means the live site (copy one), a backup on the host or a plugin schedule (copy two), and a copy pushed offsite to something like Amazon S3, Backblaze B2, or Google Drive (copy three, the one that survives your server burning down).

The offsite copy is the part people skip because it takes ten extra minutes to set up. It is also the only copy that survives a hacked host, a deleted account, or a datacenter fire. If you do one thing after reading this, connect your backup plugin to an offsite destination. That alone moves you from fragile to genuinely recoverable.

What actually breaks on real sites

Backups fail in boring, predictable ways, and almost all of them trace back to size. A small blog backs up fine forever. A WooCommerce store with ten years of orders and a 40 GB uploads folder is where the trouble starts:

• The backup job hits the host’s PHP time limit and stops partway, leaving a file that looks complete but is not.
• Someone set the plugin to exclude the uploads folder to save space, so the database restores but every product image is gone.
• The database export succeeds but is too large to import through phpMyAdmin during the restore, and now you need WP-CLI and a calm hour you do not have.
• Backups run daily but nobody checks them, so a job that has silently failed for two months is discovered the day it is needed.

None of these are exotic. They are the everyday reasons a backup that “exists” does not bring the site back. For a large or busy site, a server-level snapshot plus a separate database dump is usually more reliable than a single plugin trying to zip the whole thing inside a web request that wants to finish in 30 seconds.

How often to back up, honestly

Forget the generic “back up daily.” Match the schedule to how often your site actually changes, because your backup frequency is really a decision about how much work you are willing to lose. A brochure site that changes monthly does not need hourly backups. A store taking orders every few minutes needs real-time or hourly database backups, or a lost order is a lost customer and a support headache.

Our rule of thumb: back up the database as often as you would hate to re-enter the data, and back up the files (themes, plugins, uploads) whenever they change, which for most sites is a weekly full plus a daily database. Split the two. The database is small and changes constantly; the files are large and change rarely. Treating them on the same slow schedule is why big backups time out.

What we set up by default

For a managed WordPress site that is not enormous, our default is UpdraftPlus or Duplicator running a daily database backup and a weekly full, pushed to an offsite bucket on Backblaze B2, with a retention of at least 30 days so you can roll back past a problem you did not notice immediately. Then a restore test on staging once a quarter, on the calendar, not on vibes.

For larger or transactional sites we move the heavy lifting down to the server: scheduled filesystem snapshots from the host or the panel, plus an automated mysqldump of the database shipped offsite, because a 40 GB site should not depend on a PHP plugin finishing a zip before the request times out. Different tools, same three principles: more than one copy, at least one offsite, and a restore you have actually watched succeed.

Fast, tested backups are also what make hitting 99.9% uptime realistic, since every minute of rollback is a minute of downtime.

If your backups are the kind nobody has ever tested, that is worth fixing before you need them. We can audit what you have, run a real restore to prove it works or show you where it breaks, and set up a schedule that fits your site instead of a generic one. Start with our WordPress restoration and backup service, or the broader site restoration services if you are recovering from something that already went wrong. We timed five restore methods on a real store, from a 6-minute snapshot to a 40-minute plugin import, if you want to see what a drill looks like.