Almost every website owner we audit says the same sentence: “Backups are handled, they’re included with my hosting.” It’s said with complete confidence, and it’s the single assumption most likely to cost a business its website.
Host backups are real, and having them is better than not. But “included backups” and “a backup strategy” are different things, and the difference only becomes visible on the day you need to restore – which is the one day you can’t afford to learn it.
Hosting companies often don’t explain clearly what they offer with what package. A client came to us recently who thought she had daily hosting backups, only for us to see that her hosting provider offered backups as an option on a more expensive tier. Luckily, we caught this in time, before she needed those backups, but it was a catastrophe waiting to happen.
What host backups actually are
When a hosting plan says “daily backups included,” here is what that typically means in practice:
- A server snapshot, on the same infrastructure. Often stored on the same physical machine or, at minimum, the same provider. If the server dies, is compromised, or the account is suspended over a billing dispute, the backup can go with the site.
- A short retention window. 7 days is common on shared hosting; sometimes 14 or 30. Problems that go unnoticed longer than the window, and hacked sites routinely go unnoticed for weeks, mean every stored backup is a backup of the compromised site.
- Restores nobody has ever tested. The backup exists as a file. Whether it restores into a working website: correct database, correct file permissions, correct WordPress URLs – is unknown until someone tries. Corrupt and partial backups are discovered at restore time, by definition.
- Sometimes, not actually daily. Read the fine print: some hosts back up “periodically”, exclude databases above a size limit, or exclude the database entirely from “file backups”. Your WordPress content: every post, page, order, and form entry lives in the database.
None of this makes hosts dishonest. Backups are a checkbox feature priced into a $10/month plan; treating them as a business-continuity system is the customer’s mistake, not the host’s lie.
What can actually take your site down
A backup strategy is designed against failure modes. The realistic list:
- A bad update – the most common. You need a restore point from hours ago, not last week.
- A hack – needs retention reaching back before the compromise, which is often 30+ days back.
- Server/host failure – needs a copy stored somewhere that isn’t the host.
- Human error – deleted the wrong page, broke the theme. Needs granular, recent restore points.
- Account-level problems – billing disputes, suspended accounts, a host going out of business. Needs a copy you control.
Host backups reasonably cover #3 and partially #4. They routinely fail #1 (too coarse), #2 (retention too short), and #5 (the copy lives with the account).
The 3-2-1 rule, translated to WordPress
The old sysadmin rule says: 3 copies of your data, on 2 different types of storage, 1 of them off-site. For a WordPress business site, that translates to:
| Copy | Where | Covers |
|---|---|---|
| 1. The live site | Your host | This is the thing being protected |
| 2. Host backups | Same host | Quick rollbacks, server-side restores |
| 3. Independent off-site backup | Cloud storage you or your maintainer controls (Google Drive, S3, Dropbox…) | Everything else – including the host itself failing you |
Plus two properties that matter as much as the copies:
- Retention with history – daily points for the recent past, plus older points reaching back 30+ days, so a slow-burn problem can be rewound past its start.
- Tested restores. A backup is not real until it has been restored somewhere and produced a working website. This is the step virtually nobody does, and it’s the entire difference between “we have backups” and “we can recover.” We use LocalWP to set up your website instance on our local machine, where we can safely test backup files before doing it on the live site.
The uncomfortable audit – five minutes, right now
Answer these about your own site. “I don’t know” counts as “no”:
- If your site vanished this second, how old is the copy you’d restore – hours, or days?
- Is at least one copy stored completely outside your hosting account?
- How far back can you go? Past 30 days?
- Does your backup include the database (not just files)?
- Has anyone, ever, test-restored one of your backups and confirmed the result works?
Five yes answers: genuinely rare – you’re in great shape. Three or fewer: your website’s continued existence currently depends on nothing going seriously wrong. In our experience, 4 out of 5 websites do not have a proper backup strategy implemented.
What this costs to fix
The honest news: this is one of the cheapest serious problems to solve. Independent backup plugins with off-site storage cost $0–100/year; cloud storage for a typical site is a few dollars a month; the setup is an afternoon. The part that doesn’t come in a plugin is the discipline – the off-site copies being verified, the restore being tested periodically, someone noticing when backups silently stop running (they do).
That discipline layer is part of every one of our care plans – off-site backups with retention, restore drills included. But whether it’s us, another provider, or your own afternoon with a backup plugin: close this gap this month. It’s the highest ratio of catastrophe-prevented to money-spent anywhere in WordPress.
Not sure where your site actually stands? The free Health Check audits your backup situation as one of its seven areas — including the questions above, answered with evidence instead of assumptions.