Back up as often as the site changes. A brochure site can manage with weekly backups; a shop or booking site needs its database copied at least daily, kept for weeks and stored away from the server.

What a weekly backup promises

Most hosting plans and many maintenance arrangements include a weekly backup, and for years nobody gives it a thought.

Then something goes wrong on a Friday: a failed update, a hacked plugin, a database that will not open. The site is restored from the most recent copy, made on Sunday night.

Everything since Sunday is gone. On a brochure site that might be one changed phone number. On a shop or a booking site it is five days of orders, bookings, registrations and new customer accounts.

The backup did exactly what it promised. The promise was simply the wrong size for the site.

What changes on a busy site every day

The fourth is easy to forget. Many forms save each entry in the database as well as emailing it, and when an email goes astray, that stored copy is the only record.

The question that sets the schedule

Choose the schedule by asking how much work you could recreate by hand if the last day, or the last week, disappeared.

A shop can often rebuild lost orders from payment notifications, slowly and with some guesswork. Bookings made online usually exist nowhere else, and the customers turn up expecting them anyway.

Whatever you could not recreate, or would not want to, sets the schedule. For most shops and booking sites that means a copy of the database at least once a day, and several a day for the busiest.

The database and the files

A typical site has two parts. The files are the software, the theme and uploaded images. The database holds the pages and everything visitors create: orders, bookings, accounts and form entries.

The files change when someone updates the site or adds a photograph. The database changes every time a customer does anything at all.

So the two can follow different schedules: the database daily or more often, the files weekly and immediately before every update.

The database is usually far smaller than the files, which makes frequent copies of it cheap.

A worked example

A sailing club in a small coastal town runs its website on WordPress. Members book the club's dinghies and keelboats online, and pay for courses and memberships through the same site.

Its host made a backup every Sunday night, which had always seemed plenty for a club website.

One Friday last August, a plugin update stopped halfway and left the database damaged. The host restored Sunday's copy within the hour, and the site looked fine.

Five days of boat bookings, a run of membership renewals and the results of two evening races had vanished. The payments still existed with the card processor. The bookings existed nowhere.

Worse, the restored calendar showed boats as free that had already been taken, and members kept booking them. Volunteers spent the weekend rebuilding the schedule from confirmation emails while two crews turned up for the same boat.

The club now copies its database every few hours during the season and its files weekly, takes an extra copy before every update, and keeps the copies outside the hosting account.

A copy before every change

Updates, new plugins, theme changes and bulk imports are the moments a site is most likely to break. Take a fresh copy immediately before each one, whatever the regular schedule says.

Had the sailing club done that, the failed update would have cost an hour and no bookings at all.

Most backup tools can make a copy on demand in minutes; make it the first step of every update.

When in the day copies run

A nightly backup at two in the morning protects everything up to two in the morning. Orders taken during the following day stay exposed until the next night.

For most sites that is acceptable. For a shop that sells most in the evening, or a booking site that fills each morning, it can mean most of a day's business.

Schedule copies to land shortly after your busiest hours, rather than at whatever time the hosting plan chose.

Busy seasons need more copies

Change is rarely spread evenly through the year. A sailing club takes most of its bookings in summer, a garden centre's online orders peak in spring, and a gift shop's in December.

Raise the frequency before the busy season starts, not after the first loss, and lower it again when the season ends.

Before restoring, rescue what came after

When something breaks, the instinct is to restore the latest copy at once. Pause first. If the database still opens, export the orders, bookings and form entries made since that copy.

Payment notifications and the site's own confirmation emails are the other record. Gather them in one place before anyone starts re-entering, so nothing goes in twice.

Then restore, and fill the gap from that list. An hour of gathering can save a weekend of guesswork.

Frequency is only half of it

Frequent copies help only if they survive whatever went wrong. A copy kept on the same server shares its fate, so at least one should leave the hosting account automatically.

Keep a run of copies as well, since a hacked site can go unnoticed for days.

The counter-case

Not every site needs frequent copies. A brochure site that changes a few times a year, with forms that only send email, loses little with a weekly backup, provided copies are kept off the server.

Very frequent backups of a large shop can also slow the site while they run. Let whoever manages the hosting choose tools built for the job, and keep the copies out of the busiest hours.

For anything that takes orders, bookings or payments, back up as often as the site changes, and keep the copies somewhere else.

Before something breaks

  1. Find out when your last backup actually ran.
  2. List what visitors create on your site each day.
  3. Copy the database at least once a day.
  4. Time the copies to follow your busiest hours.
  5. Take a fresh copy before every update.
  6. Raise the frequency before the busy season.
  7. Keep copies outside the hosting account.

Step two is the one that sets everything else. The right schedule follows from what customers create on the site each day, not from whatever the hosting plan happens to include.

Why the copies also have to live outside the hosting account is covered in ransomware that targets the website itself.

Frequently asked questions

How often should a website be backed up?

As often as it changes. A brochure site can manage weekly; a shop or booking site needs its database copied at least daily, and busy ones several times a day.

What is the difference between files and the database?

Files are the software, theme and uploaded images. The database holds the pages and everything visitors create, such as orders, bookings and accounts, so it changes far more often.

When in the day should backups run?

Shortly after your busiest hours rather than at a time the hosting plan picked. Orders taken between the last copy and a problem are the ones a restore loses.

Why take a backup before every update?

Because updates are when sites most often break. A copy made minutes beforehand means a failed update costs the time to restore and nothing more.

Where should website backups be stored?

At least one copy should leave the server automatically, so a server failure, a suspended account or an attacker cannot reach the site and its backups together.

What should I do before restoring a backup?

If the database still opens, export the orders, bookings and form entries made since that copy, and gather payment and confirmation emails, so the gap can be re-entered.

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.

Weekly backups on a shop or booking site?

Tell us what your site takes online. We will suggest a backup schedule to match, with copies kept off the server.

Start a Conversation