The WordPress Backup Strategy You Only Value Once
Untested backups are hypotheses. Keep the database and the uploads, keep copies somewhere the host cannot reach, and prove the whole thing by restoring it on a normal Tuesday.
On This Page
The site goes down on a Saturday. Someone says, quite calmly, that there are nightly backups. Four hours later the calm has gone, because the archives sit on the same server that is refusing to boot, the newest one is eleven days old for a reason nobody can explain, and the only person who has ever run a restore left in March.
So here is the sentence to pin above the hosting dashboard: a backup you have never restored is a hypothesis. It is a claim about the future with no evidence behind it. The plugin reports success, the storage bill arrives, the green tick appears every morning, and none of that tells you whether the archive contains a working site.
Most WordPress backups are configured once, verified never, and discovered under pressure. That is not laziness. Backups are the only part of a website whose value stays completely invisible until the worst day of the year, and invisible things lose budget arguments to visible ones every time.
What follows is the whole of it: what an archive has to contain, how often to take one, how long to keep it, where the copies belong, and the drill that turns the hypothesis into something you can rely on. Plus the cases where a perfect backup will not help you at all.
What a WordPress backup actually has to contain
A WordPress site is two things kept in two completely different places, and a surprising number of setups capture only one of them. The failure is quiet, which is what makes it dangerous.
The database
Posts, pages, users, comments, menus, widget placement, permalink structure and every setting any plugin has ever written. It also holds the things people forget are content at all: form submissions, order records, redirect rules, custom field values, subscriber lists. Lose the database and you lose the site’s words and its configuration in the same stroke.
The uploads directory
Everything under wp-content/uploads: original images, every generated size, PDFs, downloads. The database refers to these by path, so a restore that brings back the database without the files produces a site full of broken images and empty download links, and it does it without raising a single error. That is why the two have to be captured close together in time. A database from Tuesday and uploads from the previous Thursday will disagree about what exists.
Code, configuration, and the things no archive contains
Themes, plugins, wp-config.php and any server rules such as .htaccess. If the custom theme lives in version control, that repository is already the backup for that part and does not need duplicating. What genuinely gets missed is everything outside the web root: DNS records, the certificate configuration, transactional email settings, CDN rules, API credentials held by third parties. None of it is in any archive. Write it down in a document that lives somewhere other than the server it describes.
Frequency and retention are two different decisions
Frequency answers how much work you can afford to repeat. Retention answers how far back you can reach. Teams argue about the first, quietly accept whatever default the plugin sets for the second, and then discover that a problem started five weeks ago and every copy they hold already contains it.
Set frequency by what gets created between copies, not by what feels responsible. The useful question is this: if we lost everything since the last archive, who would have to redo their work, and how much of it?
| Site type | What changes | Sensible frequency | Keep for |
|---|---|---|---|
| Brochure site, edited monthly | Almost nothing | Weekly, plus one before every change | A few months |
| Active blog or news site | Posts and media daily | Daily | A month, plus monthly archives |
| Membership or community site | Accounts, posts, comments | Daily files, database more often | A month minimum |
| Shop taking orders | Orders, stock, customers | Hourly database, daily files | Your record-keeping rule |
| Any site mid-redesign | Everything, constantly | Before and after each session | Until launch settles |
Retention wants a ladder rather than a single number: several daily copies, a few weekly ones, a handful of monthly archives. That shape is what catches slow damage, because a corrupted table, a bad bulk edit or an intrusion is often noticed weeks after it started. On a shop the calculation is sharper still, since an hour of missing orders is an hour of real transactions, which is why e-commerce builds usually separate database frequency from file frequency instead of running one schedule for both.
One point that gets skipped: an archive containing customer records is still a store of personal data. Retention is therefore not purely a technical preference, and the period you choose should match what your privacy policy already promises rather than whatever the storage plan happens to allow.
Off-site, or it does not count
The most common arrangement in the world is a backup stored on the machine it is protecting. It is the default in several popular plugins, and it is genuinely useful right up until it is not.
Same-server copies handle the everyday cases well. A plugin update breaks the layout, an editor deletes the wrong page, a theme change goes badly. Roll back, carry on. Those are real events and they are most of what actually happens to most sites.
They fail completely on the cases you bought backups for. Ransomware does not politely skip a folder named backups: it encrypts everything the compromised account can write to, and a nightly archive written by that same account is inside the blast radius by definition. A hosting account compromise reaches the control panel snapshots along with everything else. A billing failure that suspends the account suspends access to the archives too. That is the whole argument in is your backup a backup, or just a copy in the same place, and it is the single change most sites need.
A survivable arrangement looks like this.
- At least one copy with a different provider. A different folder is not off-site. A different disk on the same account is not off-site. A different company, reached with separate credentials, is.
- Push-only credentials wherever the storage supports them. If the site can write new archives but cannot delete old ones, an attacker who owns the site cannot erase its history either.
- One copy the site does not know about. A periodic download into storage holding no credentials reachable from the server. Manual is fine. Monthly is fine. Existing is the point.
- A known-good archive from before any plausible compromise. Keep one from a date you are confident about and label it, because after an incident that date is the only thing that matters.
- Restore instructions stored away from the site. A runbook on a wiki hosted on the same server is not a plan. It is a second thing to lose at the same moment.
Assume, for one minute, that an attacker has exactly the access your website has. Now list which of your backups they could reach, alter or delete. Whatever is left on that list is your real recovery position, and for a great many sites the honest answer is nothing. Fixing it is usually an afternoon of work with a second storage provider and a set of write-only keys.
The restore drill, which is the only real test
Everything above is preparation. This is the part that converts a hypothesis into a fact, and it is the part almost nobody schedules, because it takes a morning and produces no visible improvement to anything.
- Pick a copy at random, not the newest one. The newest archive is the one most likely to be fine. You want to know whether the one from three weeks ago is usable, because that is the one you will reach for after a slow problem.
- Restore into a clean environment. A separate host, a staging account or a local machine. Never over production, and never on the same account whose resilience you are testing.
- Time it from decision to working site. That number is your real recovery time, and it runs several times longer than anyone guesses, because the guess never includes hunting for credentials or waiting for a large archive to transfer.
- Check the things that break silently. Images at every generated size, form submissions, scheduled posts, redirects, licence keys, payment configuration, and whether outbound email actually sends. A page that loads is not proof of a working site.
- Write down every human decision it required. Each password nobody had, each step somebody had to remember, each thing that only worked because one particular person happened to be in the room.
- Turn that list into the runbook, and store it elsewhere. The runbook is the actual deliverable of the drill. The restored site gets thrown away; the document is what you keep.
Quarterly is a reasonable cadence for most sites, and any change to hosting, platform version or who manages what should trigger an extra one. Do it on an ordinary Tuesday when nothing is wrong, which is the only time anybody can think clearly about it.
The number that matters is not how often the backup runs. It is how long it takes to be running the site again, and only a drill can tell you that.
What a backup will not save you from
Here is the concession, and it is the reason backups are a recovery tool rather than a security control. A restore returns the site exactly as it was, which includes whatever was already wrong with it.
Restore a compromised site from yesterday and you restore yesterday’s backdoor, because the backdoor was in the site when the archive was taken. Recovery from an intrusion is therefore two jobs rather than one: go back to a copy taken before the earliest evidence of compromise, then find and close the route in, rotate every credential, and update whatever was exploited. Skipping the second job produces a site that gets reinfected within days. Scanning first tells you what you are dealing with, and what an automated scanner finds on your site today is a reasonable starting point for that.
The same faithfulness applies to fragility in general. A restore brings back the abandoned page builder, the theme nobody has updated in three years and the plugin nobody can identify. If the site was a liability before the incident it is a liability afterwards, which is why a theme can quietly become a liability is worth reading alongside a recovery plan rather than after one.
And backups cover less of the picture than people assume. DNS is not in them. Email deliverability configuration is not in them. Anything a plugin stores on a vendor’s servers is not in them. Neither is the analytics history, the search console record, or the account that holds your domain. Losing a server is survivable with good archives. Losing control of the domain is a different kind of Saturday altogether.
Reduce what has to be restored in the first place
The cheapest backup strategy is having less to back up. Every piece of content that lives somewhere with its own history is a piece you are not relying on a nightly archive to protect.
Content stored as files in a repository already carries a permanent, diffable history that no plugin has to reproduce. A workspace like Acrosite works that way: editors use structured forms, and the workspace generates the required files, commits them to GitHub and triggers the configured deployment, so the content archive becomes a side effect of publishing rather than a separate system to maintain. That does not remove the need for database backups where a database still holds orders or accounts. It does shrink the part of the site whose loss would be unrecoverable. Our parent company has written about the same idea from the editorial end in where drafts live and what stops them.
Architecture changes the blast radius too. If you run several sites, whether they share one installation and one database decides whether a single bad restore affects one brand or all of them, which is one of the less-discussed points in multisite or separate installs.
If you have just inherited the site
Do not trust the green tick. Within the first week, download an actual archive, open it, and confirm it contains both a database dump and the uploads directory at a believable size. An empty or truncated archive reports success just as cheerfully as a complete one. That check belongs in the same first pass as auditing a WordPress site you have just inherited, alongside the plugin inventory and the update history.
Then find out who holds what. Hosting login, domain registrar, DNS, storage credentials, the email sending account. Ownership tends to be scattered across former agencies and former employees, and an incident is a poor moment to discover that the only administrator address belongs to somebody who left. Sorting that out is unglamorous website maintenance work, and it pays for itself the first time anything goes wrong.
Where we would start
If you do one thing after reading this, do the drill. Not because the archives are probably broken, though sometimes they are, but because the drill is what produces the runbook, and the runbook is what makes the bad Saturday survivable by whoever happens to be available rather than by one specific person.
After that, add the off-site copy. Those two changes take a day between them and they move a site from hoping to knowing. Everything else, the frequency tuning, the retention ladder, the reduction of what needs backing up at all, is refinement on top of a position that already works.
The test we would apply is one sentence long: if you cannot name the person who would run the restore, the environment they would restore into, and the last date somebody did it successfully, you do not have backups. You have backup software, which is a different product with a similar name. If you are not sure which of the two you are paying for, tell us what you are running and when anyone last restored it.
Common questions.
How often should you back up a WordPress site?
Back up as often as you would mind repeating the work. A brochure site edited monthly is fine on weekly copies plus one before every change. An active blog needs daily. A shop taking orders needs the database far more often, because every missed hour is missed orders and stock movements. Match the schedule to what gets created between copies rather than to whatever the plugin set by default.
What does a WordPress backup need to include?
It needs the database and the wp-content uploads directory at minimum, captured close together in time. The database holds posts, pages, users, settings and plugin data, while uploads holds the media those records point at. Add themes, plugins and configuration files such as wp-config.php unless they already live in version control. Record DNS, certificate and email settings separately, because no archive contains them.
Are backups stored on the same server good enough?
No, not on their own. Same-server copies handle everyday problems well: a bad update, a deleted page, a broken plugin. They fail precisely when you need them most, because ransomware, a compromised hosting account and a suspended or failed server all take the local archives with them. Keep at least one copy with a different provider, using credentials the website itself does not hold.
How do you test a WordPress backup restore?
Restore an archive into a clean environment separate from production, then time the whole process from decision to working site. Check the things that fail quietly: images at every size, form submissions, scheduled posts, redirects, licence keys and outbound email. Note every password nobody had. Repeat quarterly and after any significant platform change, and keep the resulting runbook somewhere other than the server.
How long should you keep WordPress backups?
Long enough to reach past a problem you have not noticed yet. A ladder works well: several daily copies, a few weekly ones, and a handful of monthly archives. Corruption, a bad bulk edit or an intrusion is often found weeks later, and short retention means every copy you still hold already contains it. Archives holding customer records remain personal data, so retention has a privacy dimension too.
Will restoring a backup remove malware from a hacked site?
Only if the archive predates the intrusion. A restore returns the site exactly as it was, backdoors included, so rolling back to yesterday usually reinstates the problem. Treat recovery as two jobs: restore from a copy taken before the earliest evidence of compromise, then close the route in, rotate every credential and update whatever was exploited before the site goes back online.
Facing this in your
own business?
Tell us where you’re headed — we’ll map the shortest honest route.