Having a backup and being able to restore one are different things. Test a restore before you need it, keep a copy somewhere other than the hosting account, and know how far back the copies go.

The question that exposes it

Not "do you have backups". Almost everybody says yes, because the host mentioned it and there is a tick beside it in the control panel.

The useful question is: when did somebody last restore one, and how long did it take.

The answer is nearly always never, and that means the backup is an assumption rather than a plan.

What goes wrong with untested backups

Each is individually mundane. Any one of them turns a backup into nothing at the moment you need it.

The three-day problem

Worth singling out because it catches careful businesses.

Many hosting plans keep a rolling few days of backups. That is sufficient for a server failure, which you notice immediately.

It is not sufficient for the problems small businesses actually have. Content deleted by accident and noticed a fortnight later. A change that broke something subtle nobody spotted for a month. A compromise that sat quietly before doing anything visible.

By the time you know, every copy in the rolling window contains the problem.

Which is the argument for keeping at least one older copy, monthly if not weekly, somewhere the rotation does not reach.

The same-machine problem

The second structural weakness.

Backups stored on the same server as the site are convenient and useless against the failures that matter most: the machine dying, the account being suspended, or something with access to the site also having access to the backups.

A copy somewhere else, that the website itself cannot reach, is the difference between an inconvenience and a rebuild.

For a small business that can be as simple as a monthly download to a computer or a cloud drive. It does not require a system.

How to test one properly

  1. Take the most recent backup and confirm you can actually download it.
  2. Open it and check it contains both files and a database.
  3. Restore it somewhere that is not your live site, such as a staging area or a subdomain.
  4. Check the site actually works, not just that files arrived.
  5. Time the whole thing.
  6. Write down the steps while they are fresh.

The fifth matters because it turns an abstract reassurance into a number. Knowing a restore takes two hours changes how you think about a Friday afternoon change.

The sixth matters because the person doing this next time may be under pressure, or may not be you.

A worked example

A retailer whose site was compromised and started redirecting some visitors elsewhere.

Backups existed, taken daily, retained for seven days. The compromise was found on a Tuesday and had, on investigation, been present for around three weeks.

Every available backup contained it. Restoring any of them restored the problem.

The recovery took four days of manual cleaning, during which the site was offline, because there was no clean copy to fall back on.

What would have prevented it: one monthly copy kept aside. A single file, downloaded once a month, would have turned four days into two hours.

What to back up beyond the website

The list is longer than most people assume.

The site files and the database, which is what people mean by backups. Email, which is frequently not covered at all. Customer records held anywhere other than the site. Photographs, in their original resolution rather than the resized versions on the site.

And the things that are not data: your domain login, your hosting login, and a note of where everything lives.

That last item is what somebody else needs if you are unavailable, and it is the item nobody writes down. Keep it with the backups rather than in your head.

Who does the restoring

Worth settling before the day it is needed.

If the host holds the backups and you cannot restore them yourself, the answer is a support ticket and whatever their response time turns out to be. On a weekend that may be Monday.

If your web person holds them, the answer depends on whether they are reachable, which on a Friday evening is a genuine question.

If you hold a copy yourself, you have an option that does not depend on anybody answering. That does not mean you will do it, and it means somebody could.

The practical version for a small business is to have all three: the host's automated copies, whatever your web person keeps, and one you downloaded yourself. They cost almost nothing to duplicate and they fail in different ways.

A proportionate arrangement

For a small business, without building anything elaborate.

Daily automated backups from the host, which most plans include. A monthly manual copy downloaded somewhere else. A restore test once a year. And a written note of the steps and the logins.

That is perhaps two hours a year in total and it covers the failures that actually happen.

Anything more elaborate tends not to be maintained, which makes it worse than the simple version. A backup routine that lapsed in March is more dangerous than none, because everybody still believes it is running.

Before you change anything

The habit worth building, separate from the schedule.

Take a backup immediately before any significant change: an update, a new plugin, a redesign, a migration. Not because the change will fail, but because the cost of taking one is minutes and the cost of not having one is a day.

Most site disasters are not dramatic. They are ordinary changes that went wrong on an ordinary afternoon, and the businesses that recover quickly are the ones with a copy from an hour earlier rather than the ones with the most elaborate policy.

The related question of what the host is actually responsible for is covered in what web hosting actually buys you.


Frequently asked questions

What is the right question about backups?

Not whether you have them, but when somebody last restored one and how long it took. The answer is nearly always never.

What goes wrong with untested backups?

They stopped running, they exclude the database, they only go back three days, they live on the same machine, or nobody knows the password.

Why is a few days of retention not enough?

Because content deleted by accident, a subtle breakage, or a quiet compromise are all noticed weeks later, by which point every copy contains the problem.

Why does storing backups on the same server matter?

Because it fails against the things that matter most: the machine dying, the account being suspended, or something with access to the site reaching the backups too.

How do I test a restore?

Download the latest backup, check it contains files and a database, restore it somewhere that is not live, confirm the site works, and time it.

What is a proportionate arrangement?

Daily automated backups, a monthly copy downloaded elsewhere, a restore test once a year, and a written note of the steps and logins.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Never restored a backup?

We test one against a copy of your site, which is the only way to know it works.

Start a Conversation