A WordPress Backup Strategy That Actually Works When You Need It

Almost every site owner says they have backups. Far fewer have backups that would survive the situations people actually need them for.

The gap is rarely about frequency. It is about where the copies live, how far back they go, and whether anyone has ever tested restoring one. A WordPress backup strategy is only real if it holds up under the specific things that go wrong.

What backups are actually for

Worth being precise, because it shapes every other decision. The realistic scenarios are:

• A bad update breaks the site and rolling back is faster than debugging
• Someone deletes something — a page, a product, a plugin configuration
• The site is compromised and you need a clean copy from before the infection
• The host has a failure — hardware, corruption, or an account suspension
• You lose access to the host entirely — a billing dispute, a closed account, a developer who has moved on

Notice that two of those involve losing access to the server itself. That single observation rules out relying only on backups stored on that server.

The three rules that matter most

1. Keep a copy off the server

Host-level backups are useful and fast, but they share a fate with the thing they protect. If the account is suspended or the server fails, they may be unreachable exactly when you need them.

Keep at least one copy somewhere independent — cloud storage, or a different provider entirely.

2. Keep more history than you think

This is where most strategies fail against a compromise. Malware often sits undetected for weeks. If you keep seven days of backups and the infection is three weeks old, every copy you own is already infected.

A rolling seven-day backup protects you against mistakes. It does not protect you against a hack you discovered late.

A sensible retention pattern: daily copies for the last 30 days, weekly for three months, and monthly for a year. Storage is cheap compared with rebuilding a site.

3. Test a restore before you need one

An untested backup is a hypothesis. Backups fail quietly all the time — a job that stopped running months ago, an incomplete database export, a file that was never actually uploaded.

Restore to a staging site once a quarter. It takes an hour and it is the only way to know the system works.

How often to run them

Match frequency to how much work you can afford to lose.

• Brochure site, rarely changed: weekly is reasonable, plus a manual backup before any update.
• Blog or regularly updated site: daily.
• Ecommerce: daily files, and real-time or hourly database backups. Orders arrive at all hours, and losing a day of them is a customer service problem, not just a technical one.
• Before any significant change: always, regardless of schedule.

Back up both halves

A complete backup needs the files and the database. Missing either makes the copy close to useless.

Files means wp-content — your themes, plugins and uploaded media — plus wp-config.php and any custom root files. Core files matter less, since they can be downloaded fresh.

The database holds every post, page, product, order, user, setting and comment. Losing it means losing the site's actual content even if every file survives.

Restoring after a hack: do it carefully

This is where backups are most often misused. The instinct is to restore the most recent copy and move on. That usually reinfects the site immediately.

Three things go wrong. The recent backup already contains the malware. The vulnerability that let them in is still present, so it happens again within days. And restoring an old copy loses every order and enquiry since.

The correct sequence is: find out when the infection started, restore a copy from before that, clean it anyway to be certain, patch the vulnerability, change all passwords, then manually recover any legitimate data from the gap.

Our guide to removing malware from WordPress covers the clean-up in detail. Restoring alone is almost never sufficient.

Common mistakes worth avoiding

• Backups stored only on the same server — the single most common flaw
• Never testing a restore — you find out it was broken at the worst moment
• Too little retention — useless against a late-discovered compromise
• Backing up files but not the database, or the reverse
• Nobody checking the backups still run — jobs silently stop after a plugin or host change
• Assuming the host does it — many do, but the retention is often short and the restore is often chargeable

Read your host's actual policy rather than assuming. "Daily backups included" sometimes means two days of retention and a fee to restore.

A workable setup for most small businesses

1. Host-level daily backups, if included — fast for small mistakes
2. An independent daily backup to cloud storage you control
3. Retention of 30 daily, 12 weekly, 12 monthly copies
4. A manual backup before every update or significant change
5. A quarterly test restore to staging
6. Alerts if a backup job fails

That last point is the one people skip. A backup system nobody monitors tends to stop working quietly.

If you would rather not manage this

Backups are exactly the kind of task that feels done until the day it isn't. Our managed website plans include off-server backups with sensible retention, monitoring so a failed backup job raises an alert, and tested restores — so recovery is a routine action rather than a bad afternoon.

Get in touch and tell us what you currently have. We will tell you honestly whether it would hold up.