Backups you’ve never restored aren’t backups

Almost every website owner we talk to says they have backups. Far fewer can tell us where those backups are, how far back they go, or how long a restore takes. The honest answer to the last one is often “we’ve never tried”.

A backup only earns its keep on the worst day: a hack, a botched update, a host that goes under, or a page someone deleted a month ago. That’s a bad day to find out it doesn’t work. Here’s how to know in advance.

What needs backing up

A WordPress site is two things, and a backup needs both:

• The database: posts, pages, settings, users, orders and form entries. It changes every time someone publishes something or places an order.
• The files: the wp-content folder (uploads, themes and plugins) and wp-config.php. WordPress itself can be downloaded again, but a full copy of the files makes a restore simpler.

Then there’s what surrounds the site, which a restore quietly depends on: DNS records, server settings, scheduled jobs, SSL and email settings. Keep a written note of those, or you’ll be rebuilding them from memory under pressure.

The 3-2-1 rule

A simple rule for any data you can’t afford to lose:

• 3 copies of your data, counting the live site
• 2 different kinds of storage
• 1 copy off-site, away from the server and the hosting account

The backups most hosts include sit on the same infrastructure as the site. They’re handy for undoing a bad update. They’re no help if the hosting account is suspended, the host has a serious failure, or an attacker with access to the account deletes them. At least one copy should live somewhere else entirely, such as cloud storage in an account your business controls.

How often, and for how long

Two questions decide it:

• How much work can you afford to lose? A brochure site that changes once a month is fine with a daily backup. A shop taking orders all day needs its database backed up far more often, because every order since the last backup disappears in a restore.
• How far back might you need to go? Hacks and mistakes are often discovered weeks later. If you keep seven days of backups and the malware arrived a month ago, every copy you have is infected. We keep at least 30 days, plus older monthly copies.

The restore test

This is the step that turns a folder of files into a plan. Every few months, and after any big change to the site or the hosting:

1. Restore the latest backup to a staging site, never over the live one.
2. Click through the key pages. Log in. Check that images load, forms submit and, for a shop, that products and past orders are there.
3. Time it, from starting the restore to a working site.
4. Write down anything that didn’t work, and fix the backup setup, not just this one restore.

What restore tests turn up, in our experience:

• The backups silently stopped weeks ago, after a password change or when the disk filled up.
• The database was backed up, but the uploads folder was left out to save space.
• The backup is fine, but nobody knows the login for the storage it’s in.
• A restore takes six hours, not the thirty minutes everyone assumed.

Each of those is cheap to fix on a quiet afternoon, and very expensive to discover in the middle of an emergency.

Make failures loud

A backup that fails silently is worse than none, because it gives you false confidence. Make sure a failed or missing backup sends an alert to someone who will act on it. Glance at the sizes now and then too: a backup that suddenly shrinks by 80% usually means something is being skipped.

Before you rely on a restore

When the day comes, a few things are worth remembering:

• A restore rolls back everything. On a shop, that includes orders and customer accounts created since the backup was taken. Export recent orders first.
• Find the cause before restoring a hacked site. Putting a clean copy back over an unpatched hole just resets the clock. What to do in the first hour after a hack covers the steps that come before a restore.
• Keep the broken copy until you’re sure the restored site is right.

Your backup checklist

• The database and the files are both backed up.
• At least one copy is off-site, in an account you control.
• Backups go back at least 30 days.
• A failed backup sends an alert to a person.
• A restore has been tested in the last three months, and you know how long it took.

Off-site, versioned backups, with a restore you can ask for at any time, are part of every care plan.

Not sure your backups would work? We’ll test a restore