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.

A client of mine has been blogging for over five years, leaving her with an extensive set of archives. We needed to move her blog to a new host, so I tried exporting her archives, both as a MySQL database dump and as a WordPress XML file export. Unfortunately, the size of the files made them rather unwieldy. When I tried importing the database dump through phpMyAdmin, the page would time out before the export was complete. When I used the blog importing tool in WordPress, it would time out before it had parsed the entire file. When I tried opening the files in a standard text editor like Notepad or my preferred editor, eTextEditor, to break the files into smaller pieces, the software would crash or lock up because it couldn’t handle loading all of that information into its temporary memory.

After some Googling, I found a few tools that allowed me to break up the files into smaller pieces and easily import the information. If you find yourself in a similar situation, I hope you find them helpful.

WordPress Splitter

WordPress Splitter is a Windows program written by Ian Cull, a Mini car enthusiast, who is also rather handy with Visual Basic 6. The WordPress Splitter allows you to take the XML file created with the WordPress export tool and break it into several smaller XML files. WordPress Splitter inserts all the appropriate header information at the beginning of each file. You can also specify how large you want the split files to be.

Updated 9/28/11 – There’s now a new version of WordPress Splitter with an easier-to-use interface.

Text File Cleaver

Text File Cleaver takes a sharp knife to your text files and cuts them into smaller files, each with the same number of rows that you can specify. Small and simple, it broke up the MySQL dump so I could open the files in my text editor and get a look at what was inside it.

Big Dump

It’s got a suggestive name, but Big Dump is a great script that allows you to overcome the timeout problems encountered when you try importing a “big dump” via phpMyAdmin. First, you upload your large MySQL file to your server, then you configure the correct settings in the Big Dump PHP script. Ta da! Just run the script and your database will be imported. Be sure to remove the script and the server dump from your server when you’re done.