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.

Picking a web host can be like buying a house, you want to find a nice place for your data to live. Your blog is special to you, and the thought of having the server where your data lives come crashing down can be petrifying. Don’t let the fear paralyze you. Once you’ve decided you want to rent server space to host your own blog, here are seven things to look for when choosing a vendor.

Storage space

How much space will you need? A family of four needs a bigger place than a single college student, and the same concept applies to web servers. If you’re starting a video blog, you’ll probably need a lot of space. If your site will mostly contain text with only the occasional images, you won’t need as much. Most starter hosting plans offer up to at least 1 gigabyte of storage space, which is enough for most bloggers.

Bandwidth

Bandwidth refers to the amount of data your site transfers every month. If your home page has a 500kb of images and 20kb of text, every time someone visits your site the server hands their computer 520kb of data. Why does this cost you money? Think of you server like you do a server in a restaurant, every time they serve you a meal they earn a tip. The server has to work to hand out your site’s data. If your site is super busy, the host is going to want more money to handle the demand, just as a waiter who works a lot of tables gets a lot of tips.

Most starter plans give you ate least 10 or 20 gigabytes of bandwidth every month, which is more than enough for most amateur or beginner sites. If your site is already hosted elsewhere, you can look at your server stats to determine how much bandwidth you’ve used each month. It is important to choose a host that will let you easily upgrade to a plan with more bandwidth if needed. You should also find out what a host’s policy is if you go over the bandwidth limits. Some hosts will cut off your site for the rest of the month and other’s will start charging you extra fees.

Be wary of any site that claims to offer unlimited bandwidth. This is a lie. These sites sell shared hosting, which means you are sharing space on a certain machine with several other customers. If your site takes up a lot of bandwidth and makes the other customer’s sites run slowly, the hosting company will usually demand you upgrade to another, more expensive plan.

Backups

A blog is a dynamic beast, constantly updated not only by you but by your readers who leave comments. No hosting company is impervious to server problems. Find out if the hosting company makes regularly scheduled backups of your site. Some companies don’t make any, whereas others will make one daily, weekly or monthly. Once you’ve signed up for hosting, you should also learn how to manually download a backup just to be on the safe side. You’ll be happy you have it if your site is ever hacked by Russians.

Customer support

You’re not a web wizard, otherwise you wouldn’t be reading this article. The time will come when you need help. Is the hosting company available to answer your questions 24 hours a day? Will they be able to fix a problem if your site crashes at one o’clock in the morning. Are they polite? Most hosting companies have forums or support ticket systems, and some offer live chat services with representatives. Make sure the level of customer support meets your expectations.

Uptime

No hosting company can guarantee that your site will be up 100% of the time. Sometimes administrators need to reboot the server, just like any computer, if they’re fixing a problem or upgrading software on the machine. However, your site should be up at least 98% of the time. You can check the uptime of a host company by visiting FindMyHosting.com, clicking on the host, and then clicking on the graph icon that says “Reliability.” If your host has a lot of downtime, you might want to reconsider signing with them.

Control panel

As someone who works on lots of different sites, I prefer that web hosts use popular and commonly used web programs for server management. cPanel is a leading program that lets you manage basically everything from your blog to email to databases and more. Check to see what kind of control panel your hosting company uses, or if they have one at all. This can make the life of your web designer a lot easier or harder.

Payment terms

Some hosts offer a low rate, as little as $3 or $4 a month, however to get this rate you have to sign up for multiple years in advance, like a cell phone company that gives you a free phone if you commit to contract. I prefer to have the option to leave my host at any time in case their service starts to suffer. Check to see if you can pay month-to-month or if you have to pay annually.

Other features

Your project might require specific resources like a programming language or the ability to host many domains on the same site. Look over all the features offered in a hosting plan and make sure the hosting company is offering everything you’ll need.

It’s important to remember that there is no real “best” host, but some hosts are better than others. No one company is perfect, but if you pay attention to these eight items when choosing your vendor, your data will be living happily on a nice server in a good neighborhood for a long time.