Module 8 · 8.1

English

Nederlands English Deutsch Français Español

Backups: what, where and how often

Module 8: Backups, staging and PHP upgrades · Reading time: 9 minutes

Learning objective: After this lesson, you'll be able to create a backup plan for a WordPress website following the 3-2-1 rule.

Key concepts: backup, database, wp-content, wp-config.php, 3-2-1 rule, off the server, retention period, how often (how much work can you afford to lose), hosting backup, installer backup, backup plugin, encryption, backups outside the web directory

Why you need a backup

A backup is your way back if something goes wrong. And something always goes wrong eventually:

an update that breaks the website (lesson 7.2);
a plugin or a colleague accidentally deleting content;
a hack (lesson 7.5);
a mistake during a migration (lesson 9.5);
a server or data centre with problems;
a cancelled hosting package or an unpaid invoice, after which the host deletes your data.

Anyone without a usable backup starts from scratch in all these cases. Creating a backup is easy. Having a usable backup, one that's complete, stored in a safe place and can actually be restored, takes a plan.

What needs to be included

A WordPress website is files plus a database (lesson 1.3). A complete backup includes:

Part	Why
The database	All your text, Pages, settings, users, orders
wp-content	Themes, plugins and especially uploads (your photos and documents)
wp-config.php	The settings and keys of this installation
.htaccess and other custom files in the web directory	Redirect rules, security rules, verification files

You can always download WordPress itself (wp-admin, wp-includes) again, but it's handy if it's included: then you restore everything in one go.

Also think about what sits alongside the website: email on the same domain, the DNS records (DNS course lesson 6.3) and any cron jobs in your hosting panel. A backup of just WordPress won't restore those.

The 3-2-1 rule

A well-known rule of thumb for backups:

3 copies of your data (the original and two backups);
on 2 different types of storage or systems;
of which 1 is kept elsewhere, off the server and preferably with a different party.

Why? Because every copy in the same place can disappear at the same time. A backup in your own hosting package (such as an installer backup, lesson 2.2) is gone if the package is hacked, cancelled, or the server breaks down. A backup with your host on a different server is better, but still falls under the same party and the same account. A copy on your own computer or in a cloud storage from a different party completes the picture.

An extension you sometimes see: 3-2-1-1-0. The extra 1 is a copy that cannot be changed or deleted (offline or "immutable"), so that even an intruder or ransomware can't reach it. The 0 stands for: zero errors when testing the restore (lesson 8.2).

How often, and how long to keep them

The question of "how often" is really: how much work can you afford to lose? If only a page is occasionally updated, a weekly backup is enough. If you post news daily, do it daily. For a web shop with orders coming in every hour, a daily backup is already too little: restoring this morning's backup means today's orders are gone. There, you want more frequent backups of the database, or a host that can restore to a shorter interval.

Also important: how far back. A hack is sometimes only discovered weeks later (lesson 7.5). If you only keep the last seven days, and the backdoor is three weeks old, all your backups are infected. So also keep older backups, for example daily for a month and monthly for a year.

Who makes the backup?

There are three types, and a good plan usually uses two of them:

Backups from your host. Automatic with many hosts, of your entire package, on separate storage. With WebOké, for example, every night, keeping the past 30 nights, on storage servers in a different data centre. Check with your host: how often, how long, where, and can you restore yourself (and per component)?
Backups from your installer (lesson 2.2). Handy right before an update, but they're stored in your own package and count towards your storage. Not part of 3-2-1.
A backup plugin (for example UpdraftPlus, BackWPup, Duplicator or a paid service). This can send backups to external storage (a cloud storage, your own server). That's the easiest way to get the "1 off-site". Note: the plugin runs on your website, so it can also be affected in the event of a hack, and the login details for your external storage are stored in your database.

A simple, good plan for a small website: the daily backup from your host, plus a download to your own computer or cloud storage every month (and before every major change).

Storing safely

Never in the web directory. A backup such as public_html/backup.zip can be downloaded by anyone, complete with your database password and all customer data (lesson 7.4).
Encrypt backups that are kept outside your host, especially if they contain personal data (lesson 9.3). A backup on a stolen laptop or in a shared cloud folder is otherwise a data breach.
Store the login details for your backup storage somewhere other than the website itself, for example in your password manager. If your website is gone, you still need to be able to access it.
Tidy up: old backups in your package fill up your storage. Remove backups outside the server according to your retention period.

In practice: what it looks like in a panel

As an example, we use DirectAdmin with WebOké Backups. Other hosts have similar features, for example JetBackup in cPanel or the backup feature in Plesk.

In My WebOké, under WebOké Backups, you'll see the backups from the past nights, and you can create an extra backup or download a backup.
In DirectAdmin, under Back-up and herstel, you can create a backup yourself of whatever you tick; it's stored in your own package (in the backups directory) and can be downloaded.
In Installatron, you create a backup of one WordPress installation, handy right before an update.

Summary

A complete backup includes the database, wp-content, wp-config.php and custom files; also think about mail, DNS and cron jobs.
3-2-1: three copies, two types of storage, one off the server and preferably with a different party.
How often depends on how much work you can afford to lose; also keep older backups, because a hack can be discovered late.
Combine your host's backup with your own copy off the server; installer backups are handy, but not a plan.
Never store backups in the web directory; encrypt copies kept outside your host and store the access details somewhere else.

Quiz

Exercise

Exercise D8.1: Your backup plan following 3-2-1. Fill in the table for your own website: which copies exist (original, backup 1, backup 2), where is each copy stored (which party, which storage), how often is it made, how long is it kept, and who has access. Does your plan match 3-2-1? Then download one complete backup and check inside the file: does it include the database (an .sql file), wp-content/uploads and wp-config.php? Tick off what you found, and note down the maximum amount of work you'd lose if you had to restore your most recent backup.

Exercise D8.1: Your backup plan following 3-2-1

You do this exercise yourself; no one checks it. Tick off what you've done and mark the exercise as done.

The table with three copies filled in
The plan matches 3-2-1, or I have written down what is missing
One full backup downloaded
The .sql file found
wp-content/uploads found
wp-config.php found

Per copy: provider, type of storage, how often, retention period, who has access?

How much work could you lose at most?

Your ticks and notes only stay in this browser; we don't send them anywhere. If you're signed in, we only save in My courses that you've done the exercise.

Cookies at WebOké

Cookie settings

Necessary

Marketing