A backup stored on the same server or hosting account as the site is lost with it. Keep at least one copy somewhere separate, under separate logins, for at least a month, and test a restore.

A backup in the next folder

Ask most small businesses whether the website has a backup and they will say yes. Ask where the backup is, and the answer is usually a pause.

Often it is a plugin that zips the site every night and saves the file in a folder on the same hosting account. Sometimes it is the host's own backup, on equipment in the same building as the server.

Either way, the copy lives next to the thing it is meant to protect. Anything that takes the site down has a good chance of taking the backup with it.

What takes the backup with the site

The second is the one that catches most owners. Whatever the site's own login can reach, an intruder can reach, so a backup folder inside the account can be deleted, altered or quietly infected along with everything else.

The host's backup is not your backup

Many hosting plans mention backups, and owners reasonably assume that settles it.

Read the terms. Many hosting agreements make the customer responsible for their own backups, and the host's copies exist to recover the server after a failure, not to return one site to last Tuesday.

Some hosts keep only a few days. Some charge for each restore. Some store copies in the same data centre as the server. All of that is worth knowing before the day you need it.

What off-site actually means

An off-site copy is stored with a different provider, or at least in a different place, under different logins.

The logins matter as much as the location. If one password opens the site, the hosting account and the backup storage, one stolen password reaches all three.

The copy should be made automatically, on a schedule, without anyone having to remember. Encrypting it before it leaves the server means a stolen backup is not also a stolen customer list.

A copy on an office computer or a staff laptop counts as off-site, but only until that machine is lost, stolen or replaced.

What a complete backup contains

A WordPress site, like most sites, lives in two places: the files, including themes, plugins and every uploaded image, and the database, which holds the pages, settings, orders and form entries.

Backups that capture only one of the two are common, and they fail at the worst moment. Files without the database restore an empty site; a database without the uploads restores pages with no pictures.

Keep a written note of what a backup does not cover: where the domain is registered, the DNS settings, and where email is hosted.

A worked example

A sushi restaurant took takeout and party platter orders through a form on its WordPress site. A backup plugin saved a copy every night to a folder in the same hosting account and kept the latest ten.

An outdated plugin let someone in, and spam pages began appearing on the site. Nobody noticed for about three weeks, until a customer mentioned some strange search results.

By then all ten backups contained the intrusion. The cleanup also removed the backup folder, since every file in it was infected, and the host's own copies went back only seven days.

The site was rebuilt from the original theme files, an old export of the menu pages and a database cleaned by hand. It took most of a week, and orders came in by phone meanwhile.

Backups now go every night to separate storage, under logins used for nothing else. Daily copies are kept for three months and monthly ones for a year, and a restore is tested every quarter.

How many days to keep

Retention is the part most backup setups get wrong, because the problem it solves is invisible: damage is often discovered long after it happened.

A hacked site can carry an intruder for weeks before anyone notices. A deleted page may not be missed until somebody looks for it a month later. Ten days of backups, all made after the damage, protect nothing.

A sensible minimum for a small site is a daily copy kept for at least a month, plus a weekly or monthly copy kept longer.

A shop taking orders all day may need its database copied more than once a night.

A restore you have actually tried

An untested backup is a promise nobody has checked.

Test one by restoring it to a separate copy of the site, never over the live one. Check that pages load, images appear, the forms send and the admin login works.

Time it, and write down every step. A restore attempted for the first time during an emergency, by someone reading instructions as they go, is how a short outage becomes a long one.

Backups hold customer information too

Every backup of a site with forms or a shop contains names, email addresses, phone numbers and order details.

Never leave backup files in a folder the public can reach, where anyone who guesses the file name can download them. Know where the storage is, who can open it, and delete copies once they pass the period you chose.

From November 1, the federal privacy law, PIPEDA, will also require the organisations it covers to log each breach of their security safeguards that involves personal information. A backup file downloaded by a stranger would be one.

The counter-case

Not every site needs the same arrangement.

A brochure site that changes twice a year needs fewer backups than a shop, and a weekly copy may be enough.

Some hosts genuinely keep backups in a separate location for weeks, with free restores, and confirming that may cover most of this.

Whatever the size of the site, though, keep one recent copy somewhere other than the server, under separate logins, and prove that it restores.

The order to do it in

  1. Ask where every backup is stored.
  2. Confirm each one includes files and database.
  3. Send one copy to separate storage.
  4. Use separate logins for that storage.
  5. Keep daily copies for at least a month.
  6. Restore one to a test copy.
  7. Repeat the test every few months.

Step six is the one that turns a backup into a plan. Until a copy has been restored and checked, nobody knows whether it works, and an emergency is the worst time to find out.

Backup files piling up on the server cause the same quiet trouble described in email storage limits on a hosting plan.

Frequently asked questions

Why is a backup on the same server risky?

Because whatever takes the site down can take the backup with it: a failed disk, a hacked account, a suspended account, or a cleanup that deletes files.

Is my host's backup enough?

Often not. Many hosting terms make customers responsible for their own backups, and host copies may be short-lived, charged per restore, or stored beside the server.

What should a website backup include?

Both the files, including themes, plugins and uploaded images, and the database holding pages, settings, orders and form entries. Missing either one makes a restore fail.

How long should backups be kept?

At least a month of daily copies, with weekly or monthly copies kept longer, because hacks and deletions are often discovered weeks after they happen.

How do I know a backup works?

Restore it to a separate copy of the site, check that pages, images, forms and the login work, and write down every step and how long it took.

Do backups contain personal information?

Yes. Any site with forms or a shop stores names, emails and orders, so backups must be kept out of public folders, protected, and deleted on schedule.

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.

Not sure where your backups are?

Ask us. We will find every copy, move one off the server, and test that it actually restores.

Start a Conversation