Ask any site owner whether they have backups and the answer is yes. Ask when they last restored one and the answer is silence, a guess, or an assumption that the host handles it.
That gap is the whole problem. A backup that has never been restored is not a safeguard, it is a belief about a file. And the moment you discover the belief was wrong is, by definition, the worst possible moment.
The four ways backups quietly fail
These are the failures we actually encounter, in order of how often.
It stopped running months ago. A plugin update broke the schedule, or a storage connection expired, and nobody was watching. The plugin dashboard still says backups are enabled. The most recent one is from March.
It is on the same server as the site. If the server is compromised, ransomwared, or the account is suspended for non payment, the backup goes with the site. Storage on the same machine is a convenience copy, not a backup.
It only covers files, or only the database. Files without a database gives you a site with no content. A database without files gives you content with no theme, plugins or images. You need both, from the same moment.
It is incomplete in a way nobody notices. Large uploads folders get skipped by memory limits. Some plugins exclude directories by default. The archive completes, reports success, and is missing your media library.
The rules that actually matter
- Off site, always. Different provider, not just a different folder. Object storage or a cloud drive.
- Files and database together, from the same point in time. A mismatch between them causes its own class of problem.
- Retention long enough to catch a slow problem, as recommended in most WordPress backup guidance. Thirty days minimum. Malware and content corruption are often noticed weeks after they started, and a seven day window means every copy is already infected.
- Frequency matched to how often the site changes. Daily for a store or an active blog. Weekly is reasonable for a static brochure site.
- A copy taken immediately before any major update. This is the one that gets used most.
The official WordPress backup documentation is worth reading on what constitutes a complete copy.
The quarterly test
Here is the part almost nobody does, and it takes under an hour.
- Create a staging site or a local environment.
- Restore your most recent backup into it. Not a partial restore, the whole thing.
- Open the homepage. Open a blog post. Open a page with images.
- Log into the dashboard and confirm plugins and settings came across.
- Submit the contact form. Complete a test checkout if you have one.
- Write down the date and how long it took.
That last step matters more than it sounds. When you are dealing with a real incident, knowing that a restore takes forty minutes rather than an unknown amount of time changes every decision you make in the next hour, including what you tell customers.
Host backups are not a strategy on their own
Most managed hosts include backups and they are usually decent. Two caveats.
They are held by the same company that holds the site, so an account level problem, a billing dispute, a suspension or a provider outage, can take both. And retention is often short, commonly seven to fourteen days on standard plans.
Use them, they are genuinely useful for quick rollbacks. Just keep an independent copy somewhere else as well.
What good looks like
Daily automated backup, stored with a separate provider, thirty day retention, an extra copy before every major update, and a documented restore test performed quarterly with the date written down.
That is the standard we hold on maintained sites, and it is on our maintenance checklist. If you want to know why it matters in practice, our hacked site cleanup process is the version of this conversation where the backup was not there.
Frequently asked questions
How often should I back up my WordPress site?
Match frequency to how often the site changes. Daily for an ecommerce store or an active blog, weekly for a static brochure site. Regardless of schedule, take an additional copy immediately before every major core, theme or plugin update, because that is the copy most likely to be needed.
Are host backups enough for WordPress?
They are useful but not sufficient alone. They sit with the same provider as your site, so an account suspension, billing dispute or provider outage can affect both, and retention on standard plans is often only seven to fourteen days. Keep an independent off site copy alongside them.
How do I test a WordPress backup?
Restore it in full to a staging site or local environment, then open the homepage, a post and a page with images, log into the dashboard to confirm plugins and settings came across, and submit the contact form. Record the date and how long the restore took.
How long should I keep WordPress backups?
Thirty days as a minimum. Problems like malware infection or gradual content corruption are frequently discovered weeks after they began, and a short retention window means every available copy already contains the problem you are trying to undo.
What should a WordPress backup include?
The database and the full file system together, captured from the same point in time. That means wp-content with all uploads, themes and plugins, plus wp-config.php. Files without a database produces an empty site; a database without files produces content with nothing to render it.