You rarely ever want to be in a crash, be it a car crash, a market crash, or a blog crash. But if you are, first is covered by car insurance, the second is covered by the media, and the third is covered by me.
Recently, I had a client who needed to restore two blogs after her server crashed a few months prior. The server was home a personal site and a popular television fan site. A backup of both blogs exited, but due to various issues, she wasn’t able to obtain those files right away. The personal blog was put on hold for the time being, but the television site needed to come back online right away. Being a tech savvy client, she set up a fresh WordPress installation on a new host and kept the television blog going until she got the backup files from the old server.
When the client contacted me to restore her old entries, I realized we’d have to take different approaches to how we restored each blog. The personal site didn’t have any new data since the crash, so the simplest approach was to just restore the database for that blog. The television site required me to merge the old data (which included posts, comments, links, and tags) with the new data.
Not as simple as it looked. (The trouble with prefixes.)
The personal site sounded like an easy fix, but of course it wasn’t. The client had tried restoring the personal site’s database herself, but when she went to her blog she was faced with the WordPress installation screen instead of the posts and comments she expected. At this point she decided to call me for help.
I took a look at the database using PHPAdmin and realized that the tables in her WordPress database were missing the “wp_” prefix that is used by default. You can adjust the settings in the wp-config.php file to use whatever prefix you choose on your tables, or to get rid of the prefix completely, which appears to be what happened here.
To solve the problem, you can do one of two things. You can edit the wp-config.php file so there is no prefix. Or you can add the prefix to all the tables, as well as make edits to some values in the wp_options and wp_users tables as described here. Once I made the adjustments, the site was back up and running like it had been before. Plus, I got to feel like a magician!
Merging the old blog with the new
Next, I had to take on the trickier blog restoration. First, I set up a fresh WordPress installation on my development site and hooked it into the database the client provided me. The database was rather large, so I used Big Dump to import it quickly. I then I opened PHPAdmin and edited the site address in the wp_options table to match the address of the development blog. Then I was able to log into the site using my client’s old credentials. (NOTE: If you try viewing the WordPress blog at this point, you’ll probably see a blank screen because the template selected in the database doesn’t exist in your WordPress installation. Select a different theme and then you’ll be able to see the site.)
From there, I exported the blog using WordPress’s built-in export tool under Tools -> Export. This created a huge XML file of all the posts, comments and tags that I could import to the newer version of the blog, thus merging all the information. The XML file was a rather huge 60mb, which would most likely cause WordPress to timeout if I tried uploading it all at once. So I used WordPress splitter to divide it into 5mb files instead. Late that night, when web traffic was lighter, I imported each of the XML files into the client’s current blog. For a finishing touch, I exported her old WordPress links and imported those into her site as well. The process took about an hour to complete, but all her data was restored.
All’s well that ends well
The client was very happy with the end results. I was glad that I knew two different ways to restore WordPress blogs and knew which one fit each situation best. A straight-up database restoration is by far the quickest way, when it works, taking only a few minutes instead of the hour the XML import required. However, if you’re uncertain of your database’s integrity, like you might be if your site had been hacked, the XML import is a safe way to go too. The XML import doesn’t allow you to import any of your plug-in settings and other general settings though, which is another downer. I hope you never have a server crash, but if you do, hopefully you’ll now know how to recover from one.
