LIghtning by John Glenn at Morguefile.com

Recovering WordPress After System Failure

This site was recently offline after a server upgrade went sideways.  I upgraded my Ubuntu 10.04 Maverick Meerkat to 11.04 Natty Narwhal.  I’d upgraded a number of other systems but for some reason, this one died in mid-upgrade and then did a very unclean backout.  When the system restarted, I could no longer boot into any of the kernels on the system.  I ended up doing a clean install of 11.04 from a USB drive.

Unfortunately, when it did that, it uninstalled some applications that it found unnecessary.  Unfortunately for me, these were Apache, PHP, and MySQL, among others.  Since WordPress relies on MySQL for managing the content and runs on PHP, and I relied on Apache, you can imagine this was a problem.

Also unfortunately, I had not been regular in my WordPress backups.  I do not add much content to this site so this has been less of a disaster than it might have been.  But I had been using automysqlbackup which works great except when you don’t use it!  So I was able to quickly recover, once I had returned from a camping trip.

First, I had to reinstall Apache2 and reconfigure it to handle the sites I serve on the affected machine.  Then I needed to reinstall PHP5.  All of this was pretty straightforward and, unlike previous installs, I did not have to uncomment anything in the php.ini file to enable PHP and MySQL to talk to each other.  I then installed MySQL and I was ready to go.

The removal of those applications didn’t touch my WordPress folders, so they were completely up to date.  What I was going to lose were some of the posts I’d made in WordPress in the meantime.  I extracted the backed up sql file and attempted to reinsert it into MySQL.  Two problems arose.

The first one was curious and I’m not sure why it happened, but it was easy to solve.  The mysql user has to have rights over the folders where you are creating the database.  When I was looking into it, some people solved this by adding mysql:mysql to the group that had read/write access to the temporary folder (/tmp/).  However, that did not work for me.  Instead, I had to change ownership (chown) of the /var/lib/mysql folder so that it was owned by mysql:mysql (it was a mixture of that and root:root when I checked).  Once I did that, I was able to create the database.

Except I received a different error.  This was because MySQL did not have the user for the database so this command:

-h localhost -u wordpress_db_user -p wordpress_database_name < name_of_backed_up_sql_file.sql

would fail because the WordPress database user (created at your initial install) is not in MySQL.  You can look at the relevant /wordpress-folder/wp-config.php file to see what the username and password is.  But first you need to create the user again in MySQL.

I returned to WordPress’ famous 5 minute installation instructions and followed just the first step in the database section, to create the user and give it rights to the database.  You need to make sure that you are using the same elements that you did when you first created your WordPress site.  Then you can run the command above and you should be all set.

What about the lost content?  I have used Google’s web cache to retrieve the dozen or so posts that I had added between the time I did a backup and my server flop.  Just search cache:your_domain_name.com to pull up your old home page.  From there, I right clicked to grab the page links I wanted and then I ran the search again with cache:the_link_to_the_page so that the cache retrieved just the page I wanted.  A quick cut and paste from the cached page into WordPress’ editor window brought all the content back.  Since I already had my featured images and other content still in their upload folders, all the links continued to work properly.