Maintenance
WordPress backups: how often, where, and how to test one
25 August 2026 · 6 min read
On this page
Most people have backups. Far fewer have backups that would work. The difference only becomes apparent on the day it matters, which is the worst possible time to find out.
What a real backup includes
Files and database, both. The database holds your posts, pages, settings, users and WooCommerce orders. The files hold your theme, plugins and uploads. Either alone is useless — a database with no theme renders nothing; files with no database have no content.
Most backup plugins do both by default. Check yours actually is.
How often
Match the frequency to what you would lose:
- A brochure site that rarely changes: weekly is fine
- A site with a blog or regular edits: daily
- A shop taking orders: daily minimum, hourly during busy periods
The question to ask is not "how often should I back up" but "how much work am I willing to redo". Daily means you could lose a day. For a shop in December, that is not an acceptable answer.
And always immediately before an update. A backup from minutes ago is a genuine undo button; one from last night is a decision about what to sacrifice.
Where — and why off-site is not optional
A backup stored on the same server as the site is not a backup. It is a copy.
If the server fails, the account is suspended, or the site is compromised, you frequently lose both at once. We have seen people discover during a hosting suspension that their backups were inside the account they could no longer reach.
Off-site means somewhere genuinely separate: Google Drive, Dropbox, Amazon S3, Backblaze, or your backup provider's own storage. Most backup plugins support these for free.
Your host's backups count as a bonus, not a plan. They are usually on the same infrastructure, often kept for only a few days, and sometimes only restorable as a whole account rather than a single site.
How long to keep them
Thirty days is a reasonable default, and here is why it matters more than it sounds: most malware infections sit dormant for weeks before doing anything visible. A seven-day retention means that when you discover a compromise, every backup you hold may already contain it.
Thirty days gives you a chance of finding a clean one. Sixty is better if storage is cheap.
The test nobody runs
This is the part that separates a backup from a hope.
Once a quarter, restore one. Not to your live site — to a staging site or a local install. Then open it and check:
- Does the restore complete without errors?
- Does the site load?
- Is the content actually there, up to the date you expect?
- Do images appear, or are they all broken?
- Can you log in?
Restore failures are far more common than people assume — incomplete database dumps, missing uploads, a file size limit that silently truncated the archive months ago. An automated backup that has been quietly failing since March looks exactly like one that works, right up until you need it.
Set an alert for backup failures, too. A backup system that stops running and does not tell you is worse than no backup, because you think you are covered.
A setup that works
For most sites, this is enough and costs nothing:
- UpdraftPlus (free), scheduled daily
- Destination: Google Drive or Dropbox, not the server
- Retention: 30 days
- Email notification on failure
- A manual backup before every update
- A restore test every quarter
Steps 4 and 6 are the ones people skip, and they are the ones that determine whether any of the rest was worth doing.
What we do
Every care plan includes daily off-site backups with 30-day retention, a backup taken immediately before each update pass, and restores on request. The point is not that backing up is hard — it is that checking the backups still work is the kind of task that quietly stops happening.
If you want to know whether your current site has any backup system running at all, our free plugin checks and tells you. It is one of the more common failures we see.