WordPress delights and terrifies me. This open-source blogging platform is a wonder to use. Not easy, but easy enough, and filled with such endless possibilities. A huge number of people contribute plug-ins, themes and other bits and bobs which enhance an already powerful core.

But…it’s scary as all get out, too. After moving my website to WordPress, I soon came to realise that while it’s great to work with, it is peculiarly vulnerable to disaster. The way WordPress dumps most of your content and settings into an SQL database (come on – how many of you really understand that database?), then combines that with core code, theme code, plug-in code and your own media and other uploads; that makes for a dog’s breakfast when it comes to protecting your site from a meltdown.

Oh, there are plenty of options for backing up your system, such as VaultPress and the DB Manager plug-in – some of them back up the database, some your files, and some even back up everything. But when it comes to restoring all that stuff…well, then you’re heading into the WordPress twilight zone.

The trouble isn’t with backing up and reinstating the database or the core files or your own files; the trouble comes when you try to restore everything including all the settings for each of your plug-ins, the correct page links, the comments on your blog entries, all the nitty gritty details and linkages which took you for ever to perfect in the first place.

Once I realised the peril of working with WordPress, small things started to terrify me. The banner across the top of the WordPress dashboard saying “WordPress 2.x.x is available. Please update now” would paralyse me. I’d seen one of those small .x.x updates completely screw up a crucial plug-in before, should I risk this update now? And when WordPress 3.0 was urged upon me – not just a bug fix but a major update! – I decided the wisest course was to ignore it for as long as possible. Even though I had plenty of backups (really, I was over-backed-up using three different systems to get some sense of security), I had yet to find a single tutorial, codex or solution which gave me confidence I could restore my site if disaster struck during the upgrade.

So I ignored the update banner each time I logged in. But it nagged at me.

Could it be?

Scheduling backupsAnd then I discovered BackupBuddy. Backup and restore for WordPress. Backup everything, restore everything. Backup and move it all to another site. FTP support, Amazon S3 integration. Oh my, it sounded like this was it.

I was wary. I started reading  support forum messages and noticed that some people were having problems. A lot of those problems were host-related; in particular, GoDaddy appears to be a nasty piece of work in many ways. I don’t use GoDaddy; I use 1and1, which is mostly smooth as silk but it does have a few quirks when interacting with WordPress.

I read reviews, and found a few more problems. But some of those reviews were pretty old (why don’t people date ALL their blog posts?), and it was clear from other comments that the BackupBuddy people have been putting out revisions on a regular basis.

I read other, glowing, reviews and realised they weren’t reviews at all but simply sales affiliates repackaging the words from the BackupBuddy site.

So, maybe it was the balm for my WordPress anxiety. Maybe not.

Despite the doubts, I decided to give it a try. I bought a license, downloaded the BackupBuddy plugin, installed it into my WordPress site and took it for a whirl.

Note: If you do a Google for backupbuddy, the first thing you’ll turn up is another product of the same name. It’s a backup solution for Palms and Treos. The BackupBuddy I’m talking about is here.

Backing up

Backups work. In fact, I like BackupBuddy more than any of the other backup solutions I’ve used. You can back up your entire WordPress site or just the database. The backup is stored on your site, within the uploads directory, and you have the option to email it, FTP it or send it to an Amazon S3 bucket if you have an Amazon Web Services account. You can set up any number of backup schedules, have the completed backup automatically FTP or sent to S3, with the file on your site automatically deleted after it’s been sent off elsewhere.

It’s fast and, for me, it’s been problem free.

Restoring and migrating

Doing a blog migration with BackupBuddyThe real test of a backup, of course, is whether you can restore it. My guess is the vast majority of WordPress users have never tried a restore. I certainly hadn’t tried before BackupBuddy appeared on the scene.

So, given that my WordPress paranoia was still pretty much intact, here’s what I decided to do:

  1. Backup my main site, geekgirls.com.
  2. Restore the backup to a spare site I keep for testing purposes.
  3. If the restoration worked, I’d update that test site to WordPress 3.0.
  4. If that all went well, I’d update my geekgirls.com site to WordPress 3.0.

When you create a backup using BackupBuddy, you end up with a great big zip file with all your core WordPress files, uploads, plug-ins and themes plus a .dat file containing your WP database.

To restore your site you:

  1. Upload that zip file to the root directory of your server. You do not need to have WordPress installed in this directory; in fact, you should not have it installed.
  2. Upload a script file called importbuddy.php to the root directory of the server.
  3. Open your browser and point it to http://www.yoursitename.com/importbuddy.php
  4. Follow the step-by-step instructions to restore the site.

Not quite flawless

BackupBuddy stallsI was expecting something to go wrong, and it did. On the third step of the six-step process – when importbuddy was supposed to unzip the backup file – the script stalled. I received a message saying that my host didn’t have PHP 5.2 installed nor the ZipArchive class and so it was falling back to a slower method. In fact, my host does have PHP 5.2, but it doesn’t have the ZipArchive class. Regardless, the script stalled – or at least it hadn’t achieved anything after a couple of hours, so I assumed it had stalled.

Fortunately, I’d read that this could be a problem; the solution was to unzip the backup file, upload the unzipped contents, and then rerun importbuddy.php. So, I did that and then zoomed through the entire process without a hiccough.

The test, of course, was to see whether the newly restored/migrated site worked perfectly. I loaded it up and there it was: a fully functional clone of the original. I logged into the WordPress dashboard (I had to remember to use the username/password from my original site – that had been included in the restore) and checked everything out. It looked just fine. I clicked the link inviting me to upgrade to WordPress 3.0. The upgrade worked. The upgraded site worked.

Here’s the real magic: everything worked. BackupBuddy had even accommodated the change of domain name from geekgirls.com to the test site, and every link had been migrated without a hitch.

There was one small problem, and it’s not one I blame on BackupBuddy. I use Disqus for managing comments on my blog; the comments are stored on the Disqus servers, not on mine. Those comments didn’t make it to the new site. Now, I could have tried using the Disqus sync tool to see if I could resurrect the comments, but I thought it might cause problems because Disqus is set up to work with geekgirls.com and not my test site’s domain. So I left it as is.

I returned to geekgirls.com and upgraded it to WordPress 3.0. Perfection. Except…once again, the Disqus comments. Most of them were there, but the comments had been stripped from any post I had also viewed on the test site. Checking in the WordPress dashboard, I could see the comments were still in the database, so this time I ran the Disqus sync tool and, bingo!, all my comments reappeared.

BuddyLove

So, I’m a convert. BackupBuddy works for me, in all phases: backup, restore; site migration. Those tiny missteps in the process were just that: tiny missteps, easily correctable.

Since that first test run, I’ve upgraded to a 10-site license and I’m giving each of them the BackupBuddy treatment. I’ve set up regular schedules for each site and automatic backing up to Amazon S3. I’ve tried two more test restores and, armed with my knowledge of what could go wrong, I’ve had no problems.

I am no longer a paranoid, quivering WordPress user. I am fearless and eager and can’t wait to see the next “Please update now” message. Bring it on!