Guide · Backups
WordPress backups: a strategy that actually helps
What to back up, where, how often, how long to keep it, and the one check that makes a backup credible.
Short answer
What makes a WordPress backup actually useful?
A useful backup covers files and the database, lives somewhere other than the site’s own server, runs at a frequency proportional to what you would accept losing, and has already been restored at least once to confirm it works.
That last point is the one almost always missing. A backup that has never been restored is not a recovery guarantee. It is a recovery intention.
What to back up, and what usually gets missed
A WordPress site lives in two places, and you need both.
The files hold the theme, the plugins and above all your media: photos, documents, attachments. That is the bulky part.
The database holds everything else: pages, posts, settings, accounts, orders, form entries. That is the small and precious part.
A backup that takes only files leaves a site with no content. A backup that takes only the database leaves content with no images and no functions. Both together, taken at the same moment, make a coherent point of return.
Worth remembering
Backing up files and database separately, at different times, produces two halves that do not necessarily fit back together. They have to be taken together.
Where to keep it
The rule is short: not in the same place as the thing it protects.
A backup stored on the site’s own server disappears with it. A compromised server, a failed disk, a suspended hosting account: in all three cases the copy goes with the original.
Remote storage, a different provider, or even a regular copy downloaded and filed elsewhere is enough to break that dependency.
Careful
A publicly reachable backup is a security problem, not a protection. An archive dropped at the site root during a migration and never removed exposes your entire database, password hashes included.
How often
The useful question is not “what frequency is recommended” but how much work you would accept redoing. That is the recovery point: the largest gap between your last backup and the incident.
| Type of site | What you would lose | Reasonable frequency |
|---|---|---|
| Brochure site that rarely changes | Nothing, or one text correction | Monthly, and before every intervention |
| Site with forms | The enquiries received since the last copy | Weekly, and before every intervention |
| Blog or active site | Recent publications | Weekly at minimum |
| Store | Orders and payments | Daily, sometimes more often |
In every case, a backup before any technical intervention, whatever the regular frequency. That is the point of return in the update method.
How long to keep them
Keeping only the latest backup is a common mistake. Some problems do not show immediately: a corrupted database, content deleted by accident, a quiet compromise. If your only copy is from yesterday and the problem started last week, that copy already contains the problem.
Useful retention keeps several points in time: a few recent days, a few weeks, and a monthly point. It costs little in storage and changes everything on the day you have to go back far.
Technical detail
The technical terms you will see: RPO is how much you accept losing, expressed in time. RTO is how long you accept being down while the restore runs.
An RPO of one day with an RTO of four hours is an ordinary target for a small business. Stating it, even roughly, drives every other decision in this guide.
Are your host’s backups enough?
They are useful and often cost nothing. They are not always enough, for three reasons.
Their retention is sometimes short, a few days only. Their restore is sometimes all or nothing, with no way to recover a single file or a single table. And above all they live with the same provider: a suspended account or an incident at the host takes the site and its copies together.
The sensible combination is simple: keep the host’s, and add one somewhere else.
Test a restore, once
This is the only step that turns a backup into a guarantee. It is done once, takes an hour, and answers questions people otherwise ask at the worst moment.
What the test has to establish
- The archive opens a corrupted backup only reveals itself on opening.
- The site comes back complete pages, images, settings, accounts, not just the home page.
- You know how to do it or you know exactly who to call and how long it takes.
- You know the real duration that is your downtime on the day it happens.
- The most recent content is there the backup really covers what you thought it covered.
At Repère, a backup can be part of a maintenance intervention when it is needed, and we verify it. We do not currently provide standalone backup infrastructure with a guaranteed frequency, retention and off-site copies run as a separate service.
Worth remembering
A backup that has never been restored is not a recovery guarantee. It is a recovery intention.
Common questions
Is a backup plugin enough?
It does the job if it sends copies somewhere other than the site’s own server and if you have restored one at least once. A plugin that drops its archives in the site folder only protects against human error, not against server failure.
Should I back up before every update?
Yes, and it is the highest-return backup of all. It is what turns a failed update into a ten-minute inconvenience.
How long should a backup be kept?
Long enough to cover a problem discovered late. A few recent days, a few weeks, and a monthly point cover the large majority of cases.
How do I know my backup works?
By restoring it once, preferably somewhere other than production. That is the only answer, and there is no other.
Hand this upkeep to Repère
Verified backups before every intervention, and a written record of what was done. Twenty minutes to look at your site, then a proposal.
Hand maintenance to Repère View the free checklist