Website Backups: The Boring Habit That Saves Businesses

Here's a conversation we've had more than once. A site has been hacked, or a hosting account suspended, or an update has broken everything. We ask, "Do you have a backup?" The answer is, "Yes, the hosting company does backups." Then we check, and the most recent usable backup is four months old, or it only contains files and not the database, or it's stored on the same server that just failed.

Backups are one of those things that seem fine until the day you need them.

What a good backup includes

A website backup needs two things:

1. Files: the code, themes, plugins, uploaded images and documents.
2. Database: the content, products, orders, users, settings. For most sites, this is where the irreplaceable data lives.

A backup with only one of these is not a complete backup.

The 3-2-1 rule

A long-standing rule in IT that applies well to websites:

• 3 copies of your data
• on 2 different types of storage
• with 1 copy stored off-site

For a website, that might mean: the live site itself, a daily backup on your hosting provider, and a separate copy in cloud storage (like Amazon S3, Google Drive, Backblaze or similar) that's completely independent of your host.

How often?

It depends on how often your site changes:

• Brochure site rarely updated: weekly backups are usually fine, plus one before any change.
• Blog or content site: daily.
• E-commerce store or app with user data: daily at minimum, often more frequently for the database. A store that loses a day of orders has a real problem.

Keep several backups going back in time, not just the latest one. If your site was quietly hacked three weeks ago, yesterday's backup includes the hack. We typically keep daily backups for two weeks and weekly ones for a few months.

Test the restore

A backup you've never restored is a hope, not a plan. At least a couple of times a year, restore a backup to a test environment and check that the site actually works. It's the only way to know the backup is complete and usable.

Protect the backups

• Store them where an attacker with access to your website can't delete them. Ransomware and some attackers specifically look for backups to destroy.
• Don't leave backup files in your public website folder. We regularly find backup.zip or database.sql files that anyone could download, often containing customer data.
• Encrypt backups that contain personal data.

Have a recovery plan

Write down, even in a short document:

1. Where backups are stored and who has access.
2. Step-by-step instructions to restore the site.
3. Who to call: your developer, your hosting provider, your domain registrar.
4. Login details for hosting, domain and DNS stored securely, accessible to more than one person.

When something goes wrong, you don't want to be searching through old emails for a password.

Questions to ask today

• When was the last backup taken, and where is it stored?
• Does it include both files and the database?
• Is there a copy off the hosting server?
• When was a restore last tested?
• How long would it take to get the site back if the server disappeared today?

If any of those answers are "I don't know", that's your task for this week. It's not exciting work. But the day you need it, it'll be the most valuable thing your website has.