Verifying your backups are working
A 30-second monthly check to confirm your backups are actually running — where to look on each platform, and what to do when the answer is no.
- Time
- 30 seconds monthly
- Difficulty
- Beginner
Almost everyone with a website believes they have backups. A meaningful number of them are wrong, and they find out on the worst possible day.
The check that prevents this takes about thirty seconds a month. This page is that check.
Quick summary
Once a month, open your backup system and confirm three things: a backup ran in the last day, it finished successfully, and you can see at least 30 days of history. If all three are true, you're covered. If any one of them isn't, tell us — that's a problem worth fixing the same week.
Why this is worth thirty seconds
Backups often fail quietly. Many setups don't send you an email when they stop. A plugin update changes a setting, a storage account fills up, a payment method expires on the offsite storage, someone deactivates the plugin while troubleshooting something unrelated — and the backups simply stop, with nothing on screen to say so.
The gap between "backups stopped" and "we needed a backup" is where the damage lives. Checking monthly caps that gap at a month.
The 30-second check
A backup ran in the last 24 hours. Look at the date on the most recent backup. If it's a week old, something broke roughly a week ago.
It completed successfully. Most systems mark failed backups clearly. A run that started and didn't finish is not a backup — a half-copied database restores to nothing.
You can see at least 30 days of history. Retention matters more than people expect, because some problems aren't noticed immediately. A backup taken after a slow-growing malware infection started is a backup of an infected site.
If all three pass, you're done for the month.
Where to look
Where your backups live depends on your setup. Your project hub lists the specifics for your site; these are the usual places:
| Your setup | Where the backups are | What to check |
|---|---|---|
| WordPress on managed hosting (WP Engine, Kinsta, Flywheel) | Your host's dashboard, under "Backups" | Most recent backup date; retention window on your plan |
| WordPress with a backup plugin (UpdraftPlus, BlogVault) | UpdraftPlus: its settings screen in your WordPress dashboard. BlogVault: its own web dashboard | Last run status, and for UpdraftPlus, that the remote storage is still connected |
| WooCommerce | Same as WordPress, but orders arrive continuously | That backups run at least daily, ideally more often |
| Shopify | Shopify keeps its own platform-level data, but there is no self-serve point-in-time restore | Whether you have a backup app (such as Rewind) installed, plus a recent CSV export of products, customers, and orders |
| Webflow | Site settings → Backups (also reachable from the Settings panel in the Designer) | That you've created a manual backup before any big change |
| Squarespace | No version history and no way to restore your site to an earlier date. Deleted pages and blog posts can be restored within 30 days, and undo only works while you're editing, so treat Save as final | That anything irreplaceable, including any custom code, also exists somewhere outside Squarespace |
Host-specific walkthroughs: WP Engine, Kinsta, Flywheel, Webflow, Squarespace.
Hosted platforms are not automatically backed up the way people assume
"The platform handles it" is true for servers and software, and only partly true for your data. Shopify and Squarespace both protect their own infrastructure without giving you a one-click restore of your store or site to how it looked last Tuesday. If you're on one of these, your own exports and copies (plus a backup app, where your platform has one) are the difference between a bad afternoon and a lost catalog.
The step almost everyone skips
A backup nobody has restored is a hope, not a plan. The monthly check confirms a file exists. It doesn't confirm the file works.
Once a quarter, restore a backup to a staging site and look at it. You want to discover that a backup is corrupt on a calm Tuesday, not during an outage. If you're on a care plan we do this for you; if you're not, ask us and we'll run one.
See restoring your site from a backup for what a restore involves and how long it takes.
If the check fails
Don't wait for the next scheduled check. A broken backup gets worse every day it stays broken, because the newest safe restore point keeps aging.
Take a manual backup now if you can. Most systems have a button to start one yourself, labelled something like "Back up now" or "Create backup". It gives you a floor to stand on while the underlying problem gets fixed.
Tell us what you saw. The date of the last successful backup and any error message on screen is usually enough for us to find the cause.
Common mistakes
- Trusting the host's default without looking. Some plans back up files but not the database, and some have a retention window much shorter than you'd guess.
- Keeping the only copy on the same server as the site. A compromised or failed server takes the site and the backups together. Backups need to live somewhere else.
- Assuming a hosted platform means no backups needed. See the callout above.
- Never testing a restore. Untested backups fail more often than anyone expects.
- Letting the offsite storage lapse. An expired card on your Dropbox or Amazon S3 account can quietly stop the copies leaving the server.
Common questions
I'm on a care plan. Do I still need to do this?
No. We verify backups weekly and run test restores quarterly, and you don't need to think about it. This page is here so you know what's happening on your behalf, and so you have the check if you ever manage a site without us.
How far back should my backups go?
Thirty days of daily backups is the working minimum, with weekly copies kept longer. The reason is that some problems — a slow malware infection, a content error nobody spotted — surface weeks after they started. See how backups work.
My backup system says "successful" but the file looks tiny. Is that a problem?
Possibly. A backup much smaller than previous ones often means it captured the files but not the database, or stopped partway and reported success anyway. Send us the details and we'll check it.
Does this cover my email?
No. Website backups cover the website. Your email lives with a different provider and needs its own approach. Same for anything you keep in Google Drive, Dropbox, or a separate customer database.
Related guides
- How backups work
- Restoring your site from a backup
- Backup plugins explained
- Why backups are your safety net
- What to check on your site monthly
- What keeping a website running actually takes
- Your website disaster recovery plan
Need a hand?
Last updated