Backing up WordPress

There are, typically, three chunks of data that you need to backup so that you can recover your WordPress blog or so that you can move it to another system.

• The MYSQL database
• The WordPress config file
• The WordPress content directory

If you are doing something more complicated than a custom themed site, or if you have a multi-site implementation, then you’ll probably need to backup more things and do so differently than I’m describing here.

Note that all these instructions assume a host operating system that is a Unix variant (e.g., OS X, Linux, FreeBSD, AIX). I make no claims about whether any of this will work on a Windows host.

Backing up the database

The full instructions for backing up the database are available in the WordPress documentation. They describe at least four different ways to do it, and approach TL;DR territory. I’m just using one method – the command line and mysqldump – and want to describe backup and restore using that approach.

Essentially, you use mysqldump to create one huge SQL procedure that you can later apply to an empty database and restore all the data from the backup.

The command¹ is:

mysqldump --add-drop-table -h localhost -u adminid -p \
    databasename | gzip > databasename.bak.sql.gz

You run the command on the same system running MySQL. Replace adminid with a MySQL userid that has administrative rights for your database. Replace databasename with the database name of the site’s WordPress database.

The pipe into gzip is optional. I use gzip to compress the file. I typically maintain a rolling set of backups, so it is nice if I consume as little disk space as possible. Furthermore, I transfer copies of the backups to a local system and I want to use as little bandwidth as possible.²

Backing up the config file

This is straightforward. Just make a copy of the wp-config.php file found in the root of your WordPress installation.

Backing up the content directory

This is, essentially, all your customizations, themes, images, and any other site specific content not kept in the database. The easiest way to do this is with tar.

Here is an example using tar:

tar -c -C ~/websitehome/wpsite/wp-content . \
  | gzip > wpsite.wp-content.tar.gz

You would run this on the web host, and substitute your website’s home directory for websitehome, and substitute your WordPress directory name for wpsite (in both the tar and the gzip) statement.

The -c option tell tar to create an archive (as opposed to extracting from or appending to an archive). The -C tells tar to change it’s current directory to the location that follows (in this case ~/websitehome/wpsite/wp-content); that is done to avoid getting the parent directories in the path of the archived files. And the final . tells tar to backup the current directory. tar outputs to standard output by default, and the command pipes that into gzip to create a nice compressed archive of the wp-content directory.

Restoring from the backups

Backups aren’t much good unless you can restore from them. In this case it is pretty easy to do. The trickiest bit is, I think, the SQL database.

Restoring onto the same host

If you are doing disaster recovery and are restoring onto the same host, things are relatively straightforward. Install WordPress again, being careful to use the same database name that the original site had.

For the wp-config file you are best served by doing a diff between the installed file and the backup, and then making changes as appropriate. This is especially important if the install WordPress version is different than the one backed up.

For the wp-content folder you can rename the installed folder to wp-content-asInstalled and then extract the tar archive into the WordPress folder, using a command something like:

mkdir wp-content
cd wp-content
tar -zxf ~/backups-location/wpsite.wp-content.tar.gz

You will want to change the ownership of the wp-content folder to match the user under which the web server is running. On my local system I use the following command to do that:

chown -R _www:_www wp-content

To restore the database, first drop³ all the WordPress tables, then use the command:

gunzip -c databasename.bak.sql.gz | mysql -u adminid -p databasename

The databasename should be the database created by the new install of WordPress and should match the backed up database.

That’s it. Now, if you want to restore to a different host or different site, then it gets only just a little bit trick.

Restoring onto a different host or site

The basic steps are the same. You need to apply them in order:

1. Update the wp-config.php file – but make sure the settings match the user and database of the new installation, not the old.
2. Replace the wp-content directory.
3. chown the wp-content directory if needed.
4. Drop the WordPress tables.
5. Restore the database.

The database is a bit trickier because web site URL is stored with the content in the database. After restoring the tables you need to go through the data and replace all the old paths with the new paths.

You or I might be able to write some SQL procedures to do that, but more than likely we wouldn’t get it right and would end up with a trashed WordPress database. The good news is that someone has done all the heavy lifting for us.

The WordPress Search and Replace Tool is free and excellent. It can also be dangerous. We are fortunate that we only have to make simple changes to port the database.

To use it, just unzip the archive into the root of your site, and then browse to it. You’ll get prompted to enter the userid, password, database, and other info; if you’ve updated wp-config.php already, then it should pickup the correct information from there. Proceed to the next page and enter the search and replace strings.

In my case, where I restore to my local test WordPress installation, I just search all the WordPress tables for www.freshthought.com/jenesuispasdave and replace each with localhost:81/blog.

Once you are done with searching and replacing, delete the PHP file. It is a serious security problem to leave that in place. The authors of the utility recommend renaming the file to some obscure name before copying it into your site folder, and also insist that you remove it when you are done (no matter how obscure you named it).

To check your handiwork, flush your browser’s cache and point it a the newly restored site; you should be good to go.

Other things

I use the WordFence plugin on my public WordPress site, but not on my local system. So when I restore the database, I need to drop all the WordPress tables. You might need to do similar cleanup, depending on the mix of plugins you are using.