A working WordPress backup strategy has four parts: back up both files and database, run it on a frequency matched to how often your site changes, store copies off-site in a location separate from your hosting account, and test a restore on a schedule. Miss the last part and you do not have backups. You have files you hope are backups.
Most business sites fail on exactly that point. The plugin is installed, the schedule is green, and nobody has ever restored one. Here is how to build the whole thing properly.
What you are actually protecting against
Backups are not only for hackers. The four realistic scenarios, in rough order of how often they happen:
- A bad update. A plugin update conflicts with your theme and the site goes white at 9am.
- Human error. Someone deletes a page, overwrites a template, or empties the wrong database table.
- Hosting failure or account loss. A server dies, a migration goes wrong, or a billing lapse suspends the account. Host-level backups are inside the thing that failed.
- Compromise. Malware injected into your files, often weeks before anyone notices.
That last one shapes your retention window. If malware sat quietly for three weeks and you only keep seven days of backups, every copy you have is infected. Retention is not a storage cost question, it is a recovery question.
What to back up
A WordPress site is two things, and you need both or the restore does not work.
The database holds your posts, pages, settings, users, menus, and all plugin configuration. Everything you typed lives here.
The files hold WordPress core, your theme, your plugins, and the uploads directory with every image and PDF you have ever added.
Restore only the database and you get your content pointing at files that are not there. Restore only the files and you get an empty site. Within the files, the directory that genuinely cannot be rebuilt is wp-content — specifically uploads, themes, and plugins. Core is replaceable from a fresh download.
How often to run it
Match frequency to how much work you are prepared to redo. The answer is not “as often as possible”, it is “as often as the cost of losing a day”.
| Site type | Backup frequency | Retention |
|---|---|---|
| Brochure site, rarely updated | Weekly | 30 days |
| Business site with a blog | Daily | 30 days |
| Membership or course site | Daily, plus before changes | 60 days |
| Store taking orders | Real-time or hourly for the database | 60–90 days |
For a store, a daily backup means a full day of orders is at risk. Database backups need to run far more often than file backups there, because files barely change while orders arrive continuously.
The separate rule that catches people: run a backup immediately before any update, migration, or theme change. Scheduled backups cover accidents. A pre-change backup covers the thing you are about to do on purpose.
Where to store it
The core principle is that a backup stored on the same server as the site is not a backup. It shares every failure mode with the thing it is protecting.
A sound arrangement keeps copies in three places:
- The host’s own backups. Convenient for quick rollbacks. Not your safety net, because it is inside the account that might be the problem.
- A dedicated off-site location. Cloud object storage or a backup service, under credentials separate from your hosting login.
- A periodic local or archive copy. A monthly full download kept somewhere you control outright.
Check that your off-site location is genuinely independent. Backups sitting in a cloud drive that shares a password with the hosting account are one compromise away from being gone with everything else.
How to test a restore
This is the step that makes the rest real, and it is the step almost nobody does.
- Spin up a staging site or a local environment. Never test a restore by overwriting your live site.
- Pick a real backup, not the newest one. Take one from two or three weeks back. That is the copy you will reach for in a malware scenario.
- Restore files and database together into the staging environment.
- Check the site loads and the homepage renders correctly.
- Log into the dashboard with a known account. Broken user tables are a common surprise.
- Spot-check the things that break quietly: images loading from uploads, menus intact, forms rendering, and for a store, that orders and customers are present.
- Time it. Write down how long the whole restore took. That number is your real recovery time, and it is the one to quote when someone asks how long you would be down.
- Note what went wrong and fix the backup configuration, not just this restore.
Quarterly is a reasonable cadence for this. If your backups have never been tested, the date to do the first one is this week, because an untested backup and no backup fail identically.
Mistakes that quietly break a backup strategy
- Relying only on host backups. They are a convenience feature. They are not independent of the account.
- Backing up to the same server. Or worse, into the uploads directory, where the backup becomes both publicly reachable and part of the next backup.
- Database only. Common with plugins where someone enabled the fast option to save space.
- Retention too short. Seven days does not cover slow-moving malware or a problem noticed late.
- Never checking whether the schedule still runs. Backup plugins fail silently after plugin conflicts, licence lapses, or storage filling up. A green dashboard from three months ago means nothing.
- No pre-update backup. The most likely moment to need a rollback is the moment you are most likely to skip one.
- Publicly accessible backup files. A downloadable database dump hands over every user record and your configuration in one file.
- No notification on failure. You should get an email when a backup fails, not discover it during an incident.
A setup that works for most business sites
If you want a specific configuration rather than principles:
- Daily automated backups of files and database, run during your lowest-traffic hours.
- 30-day retention, longer if you take orders or payments.
- Primary copies to off-site cloud storage with credentials separate from hosting.
- Host-level backups left enabled as a convenience layer.
- A manual backup triggered before every update batch or structural change.
- Failure notifications going to an inbox someone reads.
- A quarterly restore test to staging, with the recovery time written down.
- One monthly archive copy pulled down and kept outside all cloud accounts.
That configuration survives bad updates, deleted pages, hosting failure, and compromise discovered late. It takes an afternoon to build and about fifteen minutes a quarter to verify.
The part that gets skipped
Almost nobody gets backups wrong at setup. They get them wrong six months later, when the plugin licence lapsed, the storage filled up, the schedule stopped running, and the dashboard still shows green. The strategy is not the hard part. Verifying it on a cadence is.
So put two recurring items on a calendar with a named owner: a monthly check that backups are actually running and the storage is not full, and a quarterly restore test to staging. Those two habits are the difference between a backup plan and a backup.
If you would rather have the schedule, the off-site storage and the quarterly restore test handled and reported on, that is covered on the Website Care Plan page.