How Often Should You Back Up Your Website?

Summary: Most website backups fail on the day they are needed, and almost always for the same three reasons: they only cover the files and not the database, they live on the same server as the site, or nobody has ever tried restoring one. This guide covers how often a Toronto business site should be backed up, what a usable backup actually contains, where it should be stored, how long to keep it, and the ten-minute test that tells you whether yours would work.

The three ways backups fail

We are called in to recover websites fairly regularly, and the pattern almost never varies. The business had backups. The backups did not help. It comes down to three things.

Only half the site was saved. A website is files plus a database. The files are the theme, the plugins, the images. The database holds every page, post, product, order and setting. Plenty of backup tools default to files only, which restores a working installation of WordPress or Joomla with none of your content in it. People discover this on the worst possible day.

The backup lived on the same server. If the copy is sitting in a folder on the machine that failed, was hacked or had its account suspended, it is gone with everything else. A backup has to be somewhere the original problem cannot reach.

Nobody ever tried restoring one. This is the big one. An untested backup is a file you hope is a backup. We have opened archives that were zero bytes, that had been silently failing for eight months, and that were technically complete but took two days to restore because nobody knew how.

How often you actually need one

The honest way to set this is to ask how much work you are prepared to do twice. Whatever changed since the last backup is what you will be rebuilding by hand.

• Brochure site that rarely changes — weekly is fine. Losing a week means losing nothing, because nothing happened in that week.
• Site with a blog, forms or regular updates — daily. A week of lost enquiries is a week of lost customers you never knew contacted you.
• Online store — hourly or continuous. Every gap is real orders, real payments and real customer records. There is no reconstructing those from memory.

If you are on a website maintenance plan, this should already be handled and you should be able to ask what the schedule is and get a straight answer.

Where the copy should live

The rule people quote is 3-2-1: three copies, on two kinds of storage, one of them off-site. For a small business site that translates to something simple — the live site, a backup with your host, and a copy somewhere else entirely, such as cloud storage or a machine in your office.

The off-site copy is the one that matters. It is the only one that survives the server being compromised, the hosting account being suspended over an unpaid invoice, or a provider going out of business. All three happen, and the last two happen more often than people expect.

For Canadian businesses there is a second consideration. If your database holds customer names, addresses or order history, that is personal information and PIPEDA applies to it — including to your backups. A copy sitting in an unsecured cloud folder is still your responsibility, and a breach of a backup is a breach.

How long to keep them

Thirty days minimum, ninety if you can. This is not about hoarding, it is about how malware behaves.

An infection rarely announces itself. It sits quietly, sometimes for weeks, before it starts injecting spam links or redirecting your visitors. By the time you notice, the compromise may be a month old — and if your oldest backup is seven days old, every single copy you hold already contains it. Restoring simply reinstalls the problem.

That is the situation behind most of the clean-up work we take on: the site can be cleaned, but the client cannot roll back to a known-good state because none of their backups predate the infection.

The ten-minute test

Everything above is theory until you have done this once.

1. Download your most recent backup to your own computer.
2. Open it. Confirm there is a database file — usually .sql — and not just folders of images and code.
3. Check the file size against last month's. A backup that suddenly shrank by 90% has been failing quietly.
4. Restore it to a staging site or a local environment. Never over the live site.
5. Log in to the restored copy and check your most recent content is there.

If you cannot complete step one because you have no idea where the backups are or who has access, that is the finding. Sort that out before worrying about the schedule.

What this costs against what it saves

Backups are unglamorous and cheap. Cloud storage for a small business site is a few dollars a month, and most maintenance plans include the whole thing.

Rebuilding a site from nothing is not cheap. If there is no usable copy, the work is a rebuild — design, structure, content, the lot — and the content is frequently the part that cannot be recovered at all, because the only copy of the words was in the database. On the numbers in what a website costs in Toronto, that is several thousand dollars to get back to where you already were, plus the weeks offline while it happens.

Common questions