Module 8 · 8.2

English

Nederlands English Deutsch

Restoring and testing

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

Learning objective: After this lesson, you can restore a backup, including alongside your existing website, and check that it's complete and usable.

Key concepts: restore, full or partial, files or database, restoring alongside the website, test restore, post-restore checklist, adjusting addresses, importing a database

A backup is only worth something if it can be restored

The most painful moment with backups isn't making them, it's discovering that restoring doesn't work: the database is missing, the backup is incomplete, the file is corrupted, or nobody knows how to do it. You'd rather discover that on a quiet Tuesday than during a hacked Saturday.

That's why you test restoring, regularly, and preferably without touching your real website.

What you restore

You don't always need to restore everything. Choose what fits:

Situation	What you restore
One page accidentally changed	Nothing: use the revisions (lesson 4.1)
An image or folder accidentally deleted	Only those files
An update broke the website	The files of that plugin or the whole wp-content, sometimes also the database (if the update changed the database)
Content deleted in the database	The database, but realise everything after that goes back too
A hack	Everything, fully (lesson 7.5), from a backup well before the hack

Files and database belong together. If you only restore yesterday's files alongside today's database, a plugin can get confused, because its database had already been updated. If in doubt: restore both, from the same moment.

And always: whatever happened after the moment of the backup, you'll lose. New posts, comments, orders, sign-ups. For a webshop, note down before restoring which orders have come in since the backup.

Restoring alongside the website

The safest way to test and to rescue things is to restore a backup alongside your current website: on a test subdomain (test.example.com) or in a separate folder, with its own database. Your real website stays untouched. Afterwards you can:

check whether the backup is complete;
take one thing from it (a deleted page, an old version of a text) and move it across by hand;
practise a recovery plan.

Some hosters can do that with a button (with WebOké Backups, for example, "restore alongside the current website"); elsewhere you put the files and database in a test location by hand.

Watch the address

A backup of https://example.com that you put on https://test.example.com still knows it belongs on example.com: siteurl and home in the database (lesson 1.3) and all links point to your real website. The result: you click on the test website and end up on the real website, or you log in to the wrong one. So after restoring, adjust the addresses:

wp search-replace 'https://example.com' 'https://test.example.com' --all-tables --dry-run
wp search-replace 'https://example.com' 'https://test.example.com' --all-tables

Or use a search and replace plugin that understands serialised data (lesson 3.2). Also switch on discourage search engines straight away (lesson 2.4) or put a password on the test website, and make sure the test website doesn't send mail to real customers (lesson 8.3).

Restoring the database by hand

If you have a .sql file (from a backup or an export), restore it like this:

Create an empty database and a user (lesson 2.3), or empty the existing one (only if you're certain).
Import the file in phpMyAdmin (the Import tab). With large files phpMyAdmin can get stuck; then use your panel's import function or the command line (wp db import back-up.sql or mysql).
Check in wp-config.php that the database details are correct.
Check the table prefix: does the one in the backup (wp_) match $table_prefix in wp-config.php? If not, WordPress sees an empty installation and wants to install again.

The checklist after restoring

A restore has only succeeded if the website really works. Check off:

The homepage and a few ordinary Pages and Posts, opened in a private window.
Images: are they there (so uploads were in the backup)?
Signing in to the Dashboard.
The most important functions: sending a form, adding something to the shopping cart, searching.
Permalinks: do all Pages work, or do you get a 404 except on the homepage? Then save once at Settings > Permalinks (lesson 2.4).
Plugins and theme active and up to date.
The version: is this really the content from the date you expected?

Note down how long the restore took. That's your real recovery time: how long your website is down in case of a problem.

How often to test

A rule of thumb: test at least once a quarter (lesson 9.4), and after every change to your backup system (a new plugin, a different hoster, a much larger website). Alternate: one time the backup from the hoster, another time your own copy stored off the server (lesson 8.1).

In practice: what it looks like in a panel

As an example we use WebOké Backups and DirectAdmin. With other hosters the buttons are named differently, but the choices are the same: what do you restore, and where.

First create the test subdomain in DirectAdmin (Subdomain Management), with a certificate.
In WebOké Backups, choose a backup from a few days ago and choose to restore the files and database alongside the current website, to the test location.
In the restored database, adjust the addresses to the test subdomain.
Go through the checklist.

Summary

A backup is only valuable if it can be restored; test the restore.
Choose what you restore; files and database should be from the same moment. Whatever happened after the backup, you'll lose.
Restore a backup alongside your website to test it or to rescue one thing, and only then adjust the addresses.
With a database import, watch the table prefix and the details in wp-config.php.
Go through a fixed checklist after every restore, and note down how long it took.

Quiz

Exercise

Exercise D8.2: Restoring a backup in staging. Restore a backup a few days old onto a test subdomain of your own domain (for example herstel.example.com), alongside your real website. Adjust the addresses, switch on discourage search engines or put a password on the test location, and go through this lesson's checklist. Tick off each point. Note down: which backup (source and date) you used, how long the restore took, what went wrong and how you fixed it. Leave the test website in place for exercise A8.3 and remove it afterwards.

Exercise D8.2: Restoring a backup in staging

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

Website restored alongside the original on a test subdomain
Addresses adjusted
Protected with a password or noindex
Gone through all points of the checklist from the lesson

Source and date of the backup

How long did it take?

What went wrong, and how did you fix it?

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