A WordPress Backup Strategy That Actually Works When You Need It

Almost everyone with a WordPress site has a backup of some kind. Far fewer have a backup that will actually get them back online after a compromise, a bad update, or a host going dark. The gap between those two things is where people lose weeks of work. This post is the backup strategy I run for client sites, written so you can copy it, and the specific ways backups quietly fail so you can check yours before you find out the hard way.

A backup you have never restored is a hope, not a backup

The uncomfortable truth first. A backup is not the file sitting in a folder. A backup is the successful restore you have actually performed. Until you have taken a backup and used it to bring a site back up, all you have is an untested assumption, and untested assumptions have a habit of failing at exactly the wrong moment.

The two failures I see most often are a plugin that has been quietly erroring for months so the last good backup is older than anyone thinks, and a backup that includes the database but not the uploads folder, or the other way round, so the restore comes back broken. Both are invisible until you need the backup. Both are caught in five minutes by a test restore.

What a complete WordPress backup contains

A WordPress site is two things that must be backed up together and restored together.

The database. Your posts, pages, users, settings, comments, and most plugin data live in MySQL. Without it the site has no content.
The files. WordPress core, your themes, your plugins, and crucially the wp-content/uploads folder with every image and media file you have ever added. Uploads are not in the database. A database-only backup loses every image on the site.

A backup that is missing either half is not a backup you can restore from. When you evaluate any backup tool or host feature, the first question is always: does this capture both the database and the full file tree, including uploads.

The 3-2-1 rule, applied to WordPress

The backup industry has a rule of thumb that predates WordPress and still holds. Three copies of your data, on two different types of storage, with one copy off site. For a WordPress site that translates cleanly.

Three copies: the live site, plus at least two backups.
Two locations: not both on the same server. This is the one people get wrong.
One off site: a copy somewhere completely separate from the host, so that losing the host does not lose the backup with it.

The rule exists because every single-location backup shares a failure mode with the thing it is backing up. A backup on the same server as the site dies with the server. A backup in the same hosting account dies with the account. Off site is the whole point.

Why a backup on the same server is not a backup

This is worth stating on its own because so many hosts offer it as if it were enough. A backup stored on the same server as your site protects you against exactly one scenario: you broke something and want to undo it. It protects you against nothing else.

It does not help if the server fails, because the backup fails with it. It does not help if the host suspends or loses your account, because the backup is in that account. And it does not help in the case that matters most, a compromise, because an attacker with write access to your server has write access to the backups sitting next to your site. Ransomware and site-wiping attacks routinely delete local backups first. The backup that saves you is the one the attacker could not reach.

How to actually set this up

You do not need anything exotic. A sensible, low-effort setup for most sites looks like this.

Pick a backup plugin or a host feature that supports remote storage. UpdraftPlus is the common free choice and sends backups to Google Drive, Dropbox, or S3-compatible storage. Many managed hosts have their own automated off-site backups. Either is fine. The non-negotiable is that a copy leaves the server.
Set the schedule to match how often the site changes. A blog that publishes weekly needs a weekly database backup at least. A shop taking orders needs daily, arguably more. Match the frequency to how much work you are willing to lose.
Back up the database more often than the files. The database changes constantly. Core, themes, and plugins change only when you update them. A daily database backup with a weekly full-file backup is a reasonable default for a content site.
Set a retention window. Keep enough history that you can go back past the point a problem started. A compromise can sit undetected for weeks, so a backup rotation that only keeps the last three days can mean every backup you have is already infected. Thirty days of history is a sensible floor.
Store the off-site copy somewhere you control, not another folder on the same host dressed up as "cloud".

Test the restore, on purpose, before you need it

This is the step everyone skips and the only step that proves the rest worked.

Spin up a staging site or a local copy, separate from production.
Take your most recent backup and restore it there in full, database and files.
Load the restored site. Check the front page, log in to the admin, open a few posts, confirm the images load.
Note how long the whole thing took. In a real incident you will want to know whether you are looking at ten minutes or three hours.
Do this again every few months, and any time you change backup tool or host.

If the restore works, you have a real backup. If it does not, you have just found out in the one situation where finding out is free.

The backup checklist

Confirm your backup includes both the database and the full files, uploads included.
Confirm at least one copy leaves the server automatically.
Set the database schedule to match how often content changes.
Set retention to at least thirty days so a slow compromise does not poison every copy.
Perform a full test restore to staging now, not later.
Note the restore time so you know what to expect under pressure.
Diary a reminder to re-test every three months.

Where this fits

The Protect My WP handbook covers backups and disaster recovery in Chapter 11, including the full off-site setup, retention strategy for catching slow compromises, and the restore-first workflow that keeps a bad day from becoming a bad month. Chapter 10 covers the monitoring that tells you something has gone wrong early enough for those backups to still be clean. A good backup is the last line of defence, and the one you least want to discover is missing.

If you want the complete disaster recovery plan rather than just the backup half, the book is where it lives.

Get the book for £19.