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
Last updated
Updated
Share

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.

Why this is worth thirty seconds

Backups often fail quietly. Many setups don't send you an email when they stop. On WordPress, for example, 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

For a backup system that runs on a schedule (a WordPress host, a backup plugin, or a backup app):

0 of 3 done

  • 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.

Saved in this browser only.

If all three pass, you're done for the month. On other platforms, the check is different: see the table below.

Where to look

Where your backups live depends on your setup. If we've invited you to a shared ClickUp space, your project hub lists the specifics for your site. Otherwise, ask us. These are the usual places:

Your setupWhere the backups areWhat 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 dashboardLast run status, and for UpdraftPlus, that the remote storage is still connected
WooCommerceSame as WordPress, but orders arrive continuouslyThat backups run at least daily, ideally more often
ShopifyShopify keeps its own platform-level data, but there is no self-serve point-in-time restoreWhether you have a backup app (such as Rewind) installed, plus a recent CSV export of products, customers, and orders. Exports don't cover everything: pages, blog posts, menus and settings would have to be re-entered by hand
WebflowSite settings → Backups (also reachable from the Settings panel in the Designer)That you've created a manual backup before any big change. On the free Starter plan, you can only restore one of the two most recent backups, unless the site's Workspace has a paid plan
SquarespaceNo 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 finalThat anything irreplaceable, including any custom code, also exists somewhere outside Squarespace
WixSite History, which records every save and publish in the editor. A restore from it only covers your pages and design: content in some Wix apps such as Stores and Blog, your contacts, site members' permissions and your CMS collections don't revertThat you've duplicated your site before any big change, since Wix can't back up your site outside Wix. For a store, export your products to a CSV file (Wix doesn't currently support exporting digital products) and export your orders. Export your contacts to a CSV file too
Custom-codedYour developer's code repository and host keep earlier versions of the code. Your data (a database or content system) is backed up separately, and how depends on the service your developer choseAsk your developer what data is backed up, how often, and when they last checked a restore

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, and Wix says it isn't currently possible to back up your site outside Wix. 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.

On WordPress, 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 your WordPress site is on our care plan, we do this for you; if it isn't, ask us and we'll run one.

On other platforms, test what you can. On Webflow, you can preview a backup before restoring it. On Wix, you can review a saved version in Site History without restoring it. On Squarespace there is no restore to test, and on Shopify there is none unless you use a backup app; check that your own copies and exports open and are complete. On a custom-coded site, ask your developer how they would restore your data, not just the code.

See restoring your site from a backup for what a restore involves on each platform.

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 backup 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. On Webflow, a site manager can save a backup by hand (if you're a content editor, ask us); on Shopify, export fresh CSV files; on Wix, duplicate your site.

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. If you pay a separate host, as most WordPress sites do: 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. For WordPress and other sites with their own hosting, 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?

If your WordPress site is on our care plan, 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.

Our care-plan backups cover WordPress sites only at this time. On Squarespace, Shopify, Webflow, Wix and custom-coded sites, keeping your own copies is up to you, so the checks in Where to look are worth doing.

How far back should my backups go?

Where you control the schedule, as on WordPress, 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. On WordPress, 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.

Was this page helpful?

Go deeper on chykalophia.com

Website care

Rather not keep on top of this yourself?

The Boring Stuff is our website care plan. Updates, backups, security and speed are looked after for you, by senior people.

Already a client? Email support@chykalophia.com.

Last updated