Ask almost any business owner if their website is backed up and you'll get a quick yes. The host said so. There's a plugin for it. Somebody set it up years ago. Then ask a second question: when was the last time anyone restored one of those backups to see if it works? That's usually where the conversation gets quiet.
A backup only matters if it can bring your site back, completely and quickly, on a bad day. Most backups that fail do so for boring reasons: they're stored on the same server as the site, they miss the database or the uploaded files, or nobody has ever tried a restore. Test one, store copies somewhere else and know how long a restore takes before you need it.
A backup is a promise until you restore it
Think of a backup like a spare tire. It's comforting to know it's in the trunk. It's a lot less comforting to find out on the shoulder of the Beltway that it's flat.
I see this a lot: a site gets hacked or an update goes sideways, the owner reaches for the backup, and it turns out the backup is incomplete, months old, or stored in a format nobody knows how to put back. The backup existed. It just couldn't do its one job.
CISA, the federal agency that publishes cybersecurity guidance for businesses, says it plainly in its guide to backing up business data: "Test backup procedure to make sure your team can rapidly restore data both fully and partially, and to ensure you can roll back data at least seven days if needed." Testing belongs in the routine.
Four ways a backup quietly fails
1. It lives on the same server as your site
If the backup sits on the same server, anything that takes out the server can take out the backup too. A hardware failure, a hacked account or a billing mix up with your host can wipe both at once. A copy that lives somewhere else survives the thing that broke your site.
2. It's missing half your site
A WordPress site has two parts. The files are the software, your theme, your plugins and every image you've uploaded. The database is a separate storage system that holds your pages, posts, settings and form entries. WordPress's own documentation is direct about it: "There are two parts to backing up your WordPress site: Database and Files." It goes on: "You need both to be able to fully restore a typical WordPress site." I've seen backups that grabbed the database and skipped the uploads folder, so the pages came back with every photo missing.
3. It only goes back one day
Some problems take weeks to notice. Malware (harmful code slipped onto a site) can sit quietly for a while. If your backup only keeps yesterday's copy, you may be restoring a site that's already infected. You want several versions going back far enough to reach a clean one.
4. Nobody knows how to put it back
A backup file on its own doesn't restore anything. Someone has to know where it is, have the logins to get to it, and know the steps in the right order. If that knowledge left with a freelancer who moved on, the file won't help you much.
How long would a restore actually take?
This is the question almost nobody asks until they're living through it. Restoring isn't instant. Someone has to notice the problem, find a good backup, restore the files and the database, then check that forms, logins and checkout work again.
Relying only on your host adds another step. WordPress's backup guide notes that "Most hosts back up the entire server, including your site, but it takes time to request a copy of your site from their backups, and a speedy recovery is critical." Waiting in a support queue while your site is down is a long afternoon.
So ask yourself two plain questions. How much work could you afford to lose, a day or a week? And how long could your site be down before it costs you real business? Your backup setup should match those answers, and a test restore is the only way to know if it does.
The 3-2-1 idea, in plain English
CISA recommends a simple rule of thumb called 3-2-1. In its words: "3 copies of important files," "2 different types of storage media (like a hard drive and the cloud)" and "1 copy stored off-site, away from your business location."
For a website, that translates roughly to this. Your live site is one copy. A backup in a separate storage service is another. A third copy lives with a different provider or in a place you control. Don't get hung up on the exact numbers. What matters is that no single failure, whether a server, a company or a password, should be able to take every copy with it.
Doing it yourself: what it really takes
You can absolutely run your own backups. Plenty of owners do. Here's what it takes to do it well:
- Tools: a backup plugin or host feature that captures files and database together, plus an outside storage account to send copies to.
- Setup time: an hour or two to configure schedules, retention (how many old copies you keep) and the offsite destination.
- Ongoing time: checking that backups ran, and doing a test restore to a spare copy of the site every so often. Plan on a couple of hours each time, more the first time.
- Skills: comfort with your hosting control panel, file managers and databases, and the patience to read error messages.
The risk when it goes wrong is simple. You find out your backups were broken at the exact moment you need them, and you're learning the restore process under pressure. If that sounds manageable, go for it. If it sounds like a Saturday you'd rather spend elsewhere, that's useful to know too.
Questions to ask your host or web team
Whoever handles your site today, these questions will tell you a lot in about five minutes:
- How often do backups run, and do they include both files and the database?
- Where are the copies stored? Is at least one somewhere other than the server my site runs on?
- How many past versions do you keep, and how far back do they go?
- When was the last test restore, and did it work?
- If my site went down right now, how long would a full restore take, and who would do it?
- Can I get a copy of my own backup if I ever leave?
That last one ties into ownership. If you're not sure who holds the keys to your site, read who should own your website. And backups are only one piece of the picture. Here's what website maintenance should include overall.
What we do, and where to start
Our hosting includes daily backups, and we actually test restores, because a backup nobody has restored is a guess. Under our care plan, the same team that knows your site handles updates, watches for problems and would be the one doing the restore if you ever needed it. No plan can promise nothing ever breaks. What it can do is make recovery a routine job instead of a scramble. You get the exact monthly price in writing before you sign.
If you'd like to know whether your current backups would actually bring your site back, ask us about a care plan.
