Restoring and testing

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

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

Key concepts: restore, full or partial, files or database, restoring alongside the website, test restore, checklist after restoring, changing addresses, importing a database

A backup is only worth something if you can restore it

The most painful moment with backups is not making them. It is discovering that the restore fails: the database is missing, the backup is incomplete, the file is damaged, or nobody knows how to do it. You would rather find that out on a quiet Tuesday than on a Saturday when you have been hacked.

That is why you test restoring, regularly, and preferably without touching your live website.

What you restore

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

Situation	What you restore
One Page changed by accident	Nothing: use the revisions (lesson 4.1)
An image or folder deleted by accident	Only those files
An update broke the website	The files of that plugin or the whole wp-content, sometimes the database too (if the update changed the database)
Content erased from the database	The database, but be aware that everything after that point goes back too
A hack	Everything, in full (lesson 7.5), from a backup made well before the hack

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

And always: anything that happened after the backup was made is lost. New Posts, Comments, orders, sign-ups. For an online shop, write down which orders have come in since the backup before you restore.

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 live website stays untouched. Then you can:

check whether the backup is complete;
take one thing out of it (a deleted Page, an older version of a text) and copy it over by hand;
practise a recovery plan.

Some hosting providers let you do this with a button (in WebOké Backups, for example, "restore alongside the current website"); elsewhere you put the files and the 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 live website. The result: you click around the test website and end up on the live one, or you sign in to the wrong one. So after restoring, change the addresses:

wp search-replace 'https://example.com' 'https://test.example.com' --skip-columns=guid --dry-run
wp search-replace 'https://example.com' 'https://test.example.com' --skip-columns=guid

First the trial run with --dry-run, then the real one; --skip-columns=guid leaves the permanent identifiers of Posts alone. Or use a search-and-replace plugin that understands serialised data (lesson 3.2 and the knowledge base article under Further reading). Also switch on discourage search engines right away (lesson 2.4) or put a password on the test website, and make sure the test website doesn't send email 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 are sure).
Import the file in phpMyAdmin (the Import tab). With large files phpMyAdmin can get stuck; then use your control 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 when the website really works. Go through:

The homepage and a few ordinary Pages and Posts, opened in a private window.
Images: are they there (in other words, were the uploads in the backup)?
Sign In to the admin area.
The most important functions: submit a form, add something to the basket, search.
Permalinks: do all Pages work, or do you get a 404 everywhere except the homepage? Then save once under 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?

Write down how long the restore took. That is your real recovery time: how long your website is down when something goes wrong.

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 hosting provider, a much larger website). Alternate: one time the hosting provider's backup, the next time your own copy outside the server (lesson 8.1).

In practice: what it looks like in a control panel

As an example we use WebOké Backups and DirectAdmin. With other hosting providers the buttons have different names, 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, pick a backup from a few days ago and choose to restore the files and the database alongside the current website, in the test location.
In the restored database, change the addresses to the test subdomain.
Go through the checklist.

WordPress: creating and restoring a backup 1:23

Summary

A backup is only valuable if you can restore it; test restoring.
Choose what you restore; files and database should be from the same moment. Anything that happened after the backup is lost.
Restore a backup alongside your website to test it or to rescue one thing, and then change the addresses.
When importing a database, watch the table prefix and the details in wp-config.php.
After every restore, go through a fixed checklist and write down how long it took.

Quiz

Exercise

Exercise D8.2: Restoring a backup in staging. Restore a backup that is a few days old on a test subdomain of your own domain (for example restore.example.com), alongside your live website. Change the addresses, switch on discourage search engines or put a password on the test location, and go through the checklist from this lesson. Tick off each item. Write down: which backup (source and date) you used, how long the restore took, what went wrong and how you solved it. Keep the test website for exercise A8.3 and delete 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