Website backups: the rule of three, and how to test a restore

The worst sentence in a rescue is “we thought we had backups”. The host offered them, or a plugin was installed once, and nobody looked again. Then the site is hacked, or a bad update wipes it, or the hosting account gets suspended, and the backups turn out to be four months old, or stored on the same server that just died, or simply not there.

The rule of three

Three copies of the site, on two different kinds of storage, with one of them somewhere else entirely.

• Copy one is the live site.
• Copy two is a backup on the host, which is convenient and fast to restore from.
• Copy three is a backup somewhere the host cannot touch: your own cloud storage, a backup service, a different provider. If the hosting account is suspended, hacked or billing fails, this copy still exists.

Most sites have copy one and a version of copy two. Copy three is the one that matters on the bad day.

What a backup has to contain

Both halves. The files, including the uploads folder where all your images live, and the database, where every page, post, setting and order lives. A backup of one without the other is half a site. Plugins that back up “the site” sometimes exclude uploads to save space. Check.

How often

Daily for any site that changes, including a site where only enquiries arrive, because the form submissions live in the database. Hourly for a shop, or a backup of the database alone every hour with the files daily. Before every update, a fresh one, whatever the schedule says.

Keep at least thirty days of them. A hack often goes unnoticed for weeks; a backup from yesterday is a backup of the hacked site. You need to be able to reach back past the infection.

Where the host’s backups fall short

Host backups are good copy two. They are poor copy three, because:

• They are on the same infrastructure. A problem at the host is a problem for the backups.
• They disappear when the account does. Suspended for unpaid invoice, closed after a hack, migrated away: the backups usually go with it.
• Their retention is often seven days, sometimes less.
• Nobody tells you when they fail. We have seen four months of silent failures.

The quarterly restore test

A backup you have never restored is a theory. Once a quarter:

1. Take the latest backup and restore it to a staging copy or a temporary subdomain. Not to the live site.
2. Open it. Check the homepage, a recent post or product, the uploads, the admin login.
3. Note how long it took and what you had to look up. That is your recovery time, and it should be written down where the next person can find it.
4. If anything failed, fix the backup process now, on a calm day.

Half an hour, four times a year. It is the difference between having backups and thinking you do.

What we do on care plans

Daily backups to off-host storage, thirty days kept, a backup before every update, and a restore test every quarter with the result in the monthly report. The reason it is part of the plan rather than a one-off setup is the silent-failure problem: backups need someone checking that they ran.

If you do not know when your site was last backed up, or where that backup is, find out this week. It is the one question you do not want to be answering on the day it matters.