Most small business owners we talk to believe their website backups have them covered. Usually the backups exist: the host takes a nightly snapshot, or a plugin sends copies somewhere. What almost none of them can tell us is the last time they restored one.
That gap matters more than people expect. A backup is a promise that you can get your site back. A restore test is how you find out whether that promise holds, and you want to find out on a quiet Tuesday, not the night your site gets hacked.
Our background is enterprise data protection and ransomware recovery, where nobody counts a backup until it has been restored. Here’s how we apply that to small business websites, including our own.
Host-level vs. site-level backups
There are two kinds of website backups, and you want both.
- Host-level backups are taken by the server on a schedule, outside of WordPress. They capture the whole hosting account: files, databases, and often email and settings. Because they don’t depend on WordPress, they still work when the site is broken, hacked or won’t load at all.
- Site-level backups run from inside WordPress through a plugin. They’re quick to take on demand and easy to restore from the dashboard, which makes them ideal right before a change.
Most sites rely on the host’s backup alone, and that leaves gaps. If the hosting account is compromised, suspended or closed over a billing problem, the backups often go with it. Many plans keep only a week or two, so malware that sat quietly for a month may be in every copy. Some hosts also charge for restores or can only restore the whole account.
Here’s how we layer them on the sites we host and manage:
- Host backups twice a day. JetBackup automatically backs up our hosting twice a day, which limits how much could be lost to roughly half a day of changes.
- A site backup before every change. Before any theme or plugin update or other major change, we take an UpdraftPlus backup, so we can roll that one site back in minutes if an update breaks something.
- Both stored offsite. Copies of both go to secure external locations outside our hosting, so a problem with the server or the account doesn’t take the backups down with it.
The two layers cover each other’s blind spots. When an update goes wrong, the site-level backup is the quick fix. When the site itself is compromised, or the backup plugin is part of the problem, the host-level backup is still there.
What bad plugin updates taught us
We’ve had to restore the Luscious Genetics store more than once after a plugin update broke it. Each time, the backup taken right before the update is what got the store back online.
Those restores taught us to stop using the live site as the test environment. Now we test updates on a clone of the site first whenever we can, and only push them to production once they’ve proven safe. We still take the backup first, because no test catches everything.
The 3-2-1 rule, for a website
The backup world has a simple rule that holds up well for small businesses:
- 3 copies of your site: the live site plus two backups.
- 2 different places to store them, such as your host and a separate cloud storage account.
- 1 copy offsite, in an account that isn’t tied to your hosting login.
For a WordPress or WooCommerce site, that usually means host-level backups plus site-level backups sent to storage you control. If that storage supports immutable or versioned backups, turn it on.
Attackers go after the backups first
We’ve spent years on the front lines of ransomware recovery for enterprise organizations. Since around 2020, the pattern has been hard to miss: before attackers encrypt anything, they go looking for the backups. A business that can’t restore is far more likely to pay.
That work helped shape how enterprise backup platforms respond to ransomware. The details stay with that work, but the lessons apply to any website:
- Attackers use the logins they steal. If the same admin login can reach your site and your backups, one stolen password reaches both. Give your backup storage its own account, a strong unique password and two-factor authentication.
- They wreck backups quietly. Snapshots get deleted, backup jobs get turned off, or retention gets shortened so the clean copies age out. Set up alerts for failed or deleted backups and for changes to backup settings.
- Locked copies survive. Immutable storage can’t be changed or deleted until its retention period ends, even by someone with the password. Keep at least one copy that way.
- Protect the backups first. When something looks wrong, the first move is to secure the backups you still have, before you start cleaning up the site.
For a deeper look at ransomware prevention and response, CISA’s free #StopRansomware resources are a good place to start.
Why backups fail when you need them
When a restore goes wrong, it’s rarely because there was no backup at all. It’s usually one of these:
- The backup quietly stopped. An expired password or a disconnected storage account can stop backups for weeks without anyone noticing. During this month’s UpdraftPlus incident, TeamUpdraft disconnected every site from UpdraftVault, and backups there stopped until someone reconnected them.
- It’s incomplete. The files are there but the database isn’t, or someone excluded the uploads folder to save space.
- It’s corrupted. The archive won’t open, or the restore fails partway through.
- It’s too old. For an online store, a week-old backup means a week of lost orders and customer accounts.
- No one knows the steps. The person who set it up is gone, the login is lost, and you’re learning the process in the middle of an outage.
Every one of these is invisible until you try a restore.
How to test a restore
A restore test doesn’t mean overwriting your live site. Restore a backup to a staging site or a temporary subdomain and check that it actually works.
- Pick a recent backup from your offsite copy, not just the host’s.
- Restore it to staging. Many hosts offer one-click staging; a temporary subdomain works too. Keep search engines from indexing it.
- Time it. Note how long it takes to get from start to a working site. That’s your real recovery time.
- Check the site, not just the homepage. Log in to the dashboard, open recent posts and pages, make sure images load, and submit a contact form. For a store, confirm recent orders are there and run a test checkout.
- Write down the steps, including where the backups live and how to log in, so someone else could do it.
Do this at least once a quarter, and again after any big change: a new host, a redesign, a new backup plugin or a new storage account. A bonus: the restored staging copy makes a good clone for testing updates before they reach your live site.
Two questions that set your backup schedule
- How much can you afford to lose? A brochure site that changes once a month can live with weekly backups. A busy store may need backups several times a day, so one bad night doesn’t wipe out a day of orders. In enterprise terms, this is your recovery point objective (RPO).
- How long can you afford to be down? If your site brings in sales or leads, every hour offline costs you. Your restore test tells you whether your current setup meets that number. This is your recovery time objective (RTO).
If the answers surprise you, that’s the point. It’s better to learn it now.
A quick website backup checklist
- Host-level backups run automatically, on a schedule that matches how often your site changes.
- A site-level backup is taken before every update or major change.
- Updates are tested on a clone or staging site before they go live.
- At least one copy is stored outside your hosting account, ideally immutable.
- Backup storage has its own login with two-factor authentication.
- You get an alert when a backup fails, not only when it succeeds.
- You’ve restored one in the last three months, and you know how long it took.
- The steps are written down somewhere besides one person’s head.
Want a second set of eyes?
If you’re not sure your website backups would hold up, we can review your setup, add offsite copies, and walk through a restore test on staging so you know exactly where you stand. Send us an email and tell us a little about your site.