How to check that your website backups would actually work

Most owners find out how their website backups work on the day the site breaks. An update goes wrong or the hosting account gets hacked, someone says "we'll just restore it," and then the backup turns out to be months old, or it sits on the same server that just failed. By then the only fix is rebuilding pages from memory and old emails, which takes far longer than anyone expects, and it plays out the same way for a pool service in Boca Raton as for a dental practice in Stockport.

This is one of the most common gaps in website backup for business sites, and it's also one of the cheapest to close before anything goes wrong. You don't need to be technical to check it. You need to know what a usable backup looks like, and you need to see one restore actually work. Everything below is something you can check or ask about this week.

What a usable website backup for business includes

A website is made of two parts that are stored in different ways. The files are the design, the code, the add-ons and every image or PDF you've ever uploaded, like the before-and-after photos from a boat dock job. The database holds the words and the records: pages, blog posts, form submissions and settings, plus orders and customer accounts if you sell or take bookings online.

A backup that only has one half can't bring the site back. Files without the database give you a site with the right look and no content, and a database without the files gives you content with nowhere to show it. In our experience, partial backups are more common than owners expect, usually because a hosting plan's automatic backup covers one part and nobody set up the other.

So the first thing to confirm is that each backup contains both parts, and that both were taken at the same moment. Beyond that, a usable backup lives somewhere other than your website's server, and enough copies are kept that you can go back several weeks.

Where the copies live, and how long they're kept

If the backup is stored on the same server or in the same hosting account as the website, whatever takes the site down can take the backup with it. That might be a hardware failure, an account that gets hacked, a hosting bill that lapses and closes the account, or someone with access deleting the wrong folder. A copy kept somewhere separate, ideally with a different provider, survives all of those.

The same logic applies to copies kept in the office. A drive sitting in a back office in Fort Lauderdale goes wherever that office goes, which is a real worry during Florida hurricane season, when a flooded ground floor or a long power cut after a storm can take out everything plugged in under the desk. A laptop that lives in the van of a trades business in Bolton can be stolen along with the tools. Those copies are fine as an extra, but the main one should be stored with a provider in a different place.

Ownership matters here as well. Backups should sit in an account your business owns or can get into, so that if you part ways with your designer or agency you aren't left asking them for a copy of your own website.

How long copies are kept is the part people overlook. Hacked sites often run for weeks before anyone notices odd redirects or spam pages, and if your setup only keeps the last few days of backups, every copy you have may already include the problem. Keeping several weeks of history gives you a clean point to go back to.

How often backups run depends on how often the site changes. A shop or booking site changes every day, so it needs a daily backup. A brochure site that gets edited once a month can usually live with weekly copies, as long as someone also takes a manual backup right before any update or redesign.

The questions to send whoever runs your site

Whoever looks after your site should be able to answer these in writing, in plain language, without needing a week to find out. Ask them to tell you:

1. Where the backups are stored, and whether that's a different provider or location from the website itself.
2. Whether each backup includes both the files and the database.
3. How often backups run, and how many weeks back you can go.
4. Who gets told if a backup fails, and when that last happened.
5. When the last test restore was done, and what exactly was restored.
6. How you would get a copy of the site if they weren't available tomorrow.

A good answer is specific. Something like "daily, files and database together, stored with a separate provider, kept for eight weeks, last test restore two months ago, and you have your own login to the storage" tells you someone has thought about it.

Vague answers sound like "the host takes care of that" or "it's all backed up automatically." Those aren't always wrong, but they usually mean nobody has looked. Many hosts do keep their own short-term copies, and those are worth having. In our experience, though, they're often kept only briefly, and restoring one sometimes means a support ticket and an extra fee. Treat the host's copies as a bonus on top of a backup you control.

Ask for proof alongside the answers: a screenshot of the backup list showing dates. If you have your own hosting login, you can check this yourself. Log in to the hosting control panel and look for a section called Backups or something close to it, then look at the date on the newest entry and whether older entries are listed below it. If the newest copy on a busy site is more than a week old, or there's only one copy, you have your answer.

A test restore is the only real proof

Everything above tells you a backup exists. It doesn't tell you the backup works, and the only way to find that out is to rebuild the site from it.

The safe way to do this is a restore to a staging copy. That's a private copy of your site at a separate address that visitors and search engines can't see, so the live site isn't touched while you test. Most hosts can create one, and anyone who manages websites will know how.

Once the staging copy is restored, go through it yourself with a short checklist:

• The home page and your main service pages load and look right.
• The most recent change you made, such as a new blog post or an edited price, is there.
• Images and downloadable files open instead of showing broken links.
• The contact or booking form sends a test message that actually arrives.

Also ask how long the restore took from start to finish, and write it down. That number is what you'd be living with on a bad day, and it's useful to know before you need it.

In our experience, a first test restore finds something more often than not: a missing folder, a form that no longer sends, a database copy from a different day than the files. That's the point of doing it now. Fix what's missing, then test again. After that, a test restore twice a year and after any big change, such as a redesign or a move to a new host, keeps the answer current.

How Pixedi handles this in Care

In our Care plan, $250 a month, backups are part of the website care and security work, alongside uptime and email health. Every owner gets one plain report a month that says what we did and what changed, and they never have to log in anywhere to see it.

What to do this week

Today, copy the six questions above into an email to whoever runs your site, and ask for written answers by the end of the week along with a screenshot of the backup list with dates. When the answers come back, save them somewhere you can find them, then put a test restore to a staging copy on the calendar for the next two weeks and go through the checklist yourself when it's done.

Ask AI about this article

Opens the assistant in a new tab with this page as the source.

ChatGPTClaudePerplexityGemini