The reason that BackupBuddy is stirring up so much excitement in the WordPress community is that when it works (more on that in a minute), it’s so comprehensive that you can actually use it to move your WordPress installation from one server to another without having to do anything more than set up a MySQL database. That gets the developers who work on sites in one environment and then move them to another one excited, because it’s a time-saver. And it gets people who’ve had their web servers hosed excited, because they can get back up and running quickly.
BackupBuddy is a commercial product: unlike most WordPress plugins, you have to pay for it. It’s $25 for a single-user license, $75 for a business license, and $150 for the developer license. You can start with a single-user license and upgrade.
When I contacted iThemes and asked for a review copy, Cory Miller provided me with a 3-month subscription good for two sites.
After you buy the plugin (or, um, don’t, if you’re a reviewer), iThemes sends you an e-mail with a login and password for the membership site. That’s where you go to download the actual plugin, which you then upload and install to your WordPress site in the usual fashion. I opted to try BackupBuddy on FileSlinger.com (still hosted at GoDaddy because I didn’t get my act together to switch before the plan auto-renewed) and on the test blog I keep for the Podcast Asylum (hosted at Dreamhost, courtesy of the Ur-Guru.)
There’s an additional step, however. Before you can start using BackupBuddy, you have to get a license. When you click “Manage Licenses,” an AJAXy lightbox-effect window pops up and tells you how many license keys are available to you. The first time you use BackupBuddy, you’ll need to generate a key and link it to the site. If you later want to use BackupBuddy on a different site instead, you can go into the license manager and click “unlink from site,” then deactivate and uninstall the plugin.
Once you have the license in place, you’ll see the BackupBuddy options panel in the WordPress dashboard. This is where you set your backup password and schedule, and also where you find the instructions on how to use the plugin. (Looking at the screenshot, it occurs to me that it might be more logical to put “Settings” right after “Getting Started.”)
BackupBuddy is designed to be easy to use, though it’s not quite at the ease-of-use level I’d recommend for my mother:
- Set a password in the Settings section if you have not done so.
- Perform a full backup by clicking Begin Backup on the Create Backup page. This may take several minutes.
- Perform database backups regularly to compliment [sic] the full backup as the database changes with every post and are smaller than full backups.
- Download the backup importer, importbuddy.php, for use later when restoring or migrating.
- Upload the resulting backup zip file and importbuddy.php to the root web directory of the destination server.
You do not need to install WordPress or any other files on the destination server. [My emphasis.] The backup will handle this.
- Also upload the latest database backup ZIP file if one exists.
- Navigate to importbuddy.php in your webbrowser on the destination server.
- Follow the importing instructions on screen. You will be given the option to change settings on import.
- After completing the restore / migration, repeat the process, selecting the database backup zip on import.
I’m not sure why they ask you to start by creating a password, because so far I haven’t needed to use it. The rest of the settings are for your FTP server login info if you are backing up that way.
BackupBuddy saves its backups to a folder on your web server. Right now there are two options for what it can do with backups once they’re complete: upload them to another server by FTP, or e-mail them to you. Personally, what I want to do with them is download them, without having to turn my laptop into an FTP server. I suspect the easiest way to accomplish that would be to have the program e-mail me when the backups are ready, so I can go get them myself. A few people in the support forums have also requested Amazon S3 as a possible backup destination, and I suspect we’ll see some new options in the future.
You can create multiple backup schedules—say, a full backup once a month and a database backup weekly, daily, or even hourly (depending on how often you post to your blog). E-mailing database backups isn’t usually a problem, but you don’t want to send your entire site backup (the one I made for FileSlinger.com was about 42 MB) via e-mail. Either FTP it to another server (preferably on another host) or download it to your hard drive and have it included in the backups you make offline. (I suppose I could create a monthly backup schedule and then just set up a reminder in Outlook, but it would be really nice if BackupBuddy could do this itself somehow.)
It was with great eagerness that I set out to make my first backup on the test blog, but I immediately ran into problems:
Backing up database……………………………………
ZipArchive class not available. This is typically the case if your server runs PHP 5.1 or older.
Falling back to compatibility method. Note that this method is slower.
When I downloaded the backup, all it contained was the database, even though I’d set out to make a full backup. To make matters more confusing, when I checked with the Ur-Guru about the PHP version, he said that the server my site was on used PHP 5.2. Nevertheless, there was apparently no ZipArchive class, and so BackupBuddy couldn’t work properly. I reported the issue to Cory, who passed it on to lead developer Dustin Bolton, and also posted it in the Support Forum.
Meanwhile, I tried creating a backup on FileSlinger.com and had better luck.
When I downloaded that backup and opened the .zip file, it looked complete to me. I later learned that it hadn’t been, quite. Dustin and the team have put out at least three updates since I first installed BackupBuddy, and now they report to you on the condition of the backups. The following list comes from the test blog over at Dreamhost.
As for what was happening when I tried to run the backups, I went from the “ZipArchive class” errors to getting a 404 page. Yet when I would go back to the “backups” page, there would be backups—in that invalid format. (Definitely invalid: I downloaded one and tried to back it up.) Something must be happening, because these files are larger than the first backups, but I couldn’t really tell you what, or where the problem originates.
I’m all in favor of having a program tell me when a backup is no good, though. That’s critical information. It might be something you want an e-mail message about if it happens with a scheduled backup instead of a manual one, but I suspect that just getting BackupBuddy to work on the major hosts is a more pressing problem right now.
There’s a 46-minute video introduction that walks you through the steps of backing up and restoring your site with BackupBuddy. Otherwise, support comes from the Support Forum, and responses from iThemes tend to appear in the evening. The guys are obviously working very hard to address the issues their users have been raising, given the number of new builds they’re putting out, but I just don’t think there are enough of them to keep up with BackupBuddy’s popularity.
Of course, no backup is any good unless you can restore your data from it. I’d hoped to do that test with the test blog, since there’s nothing to lose with it. But since the only good backup I could get was of the Backup Blog, I needed to test my restore on GoDaddy, even though I’d seen in the support forums that there could be issues there, too.
So I created a new directory in my main hosting account and uploaded the backup .zip file and the import.php file there, then navigated to the import.php file in my browser. and voila!
Step 1 was both easy and obvious: I’d only uploaded one backup, so I didn’t have to worry about which file to choose from that drop-down menu. I just clicked “Next Step” and went on. Steps 2 and 3 were similarly straightforward.
Step 4 was where it got interesting. The program pulled the database info straight out of my wp-config.php file (including the password). It occurred to me (and if it hadn’t, there was that warning to tell me) that I might not want to overwrite my existing database information, so I changed the database prefix, a trick that lets you use the same database for more than one blog. Then I went on to Step 5…
That was as far as the restoration process ever got. A little reading in the support forum suggested that GoDaddy is inclined to kill scripts that take more than 30 seconds to run. (This didn’t happen when I was making the backup, but who knows?)
I tried navigating to the site’s home directory to see what I could find, and discovered that my theme was there but I got a 404 on the home page.
Wondering whether I’d have better luck if I tried using a new database, I set one up and ran import.php again. Same result.
This is, shall we say, a tiny bit frustrating. It’s like having the Holy Grail just beyond reach of my fingertips. It almost works. It works well enough, in fact, that I could use it to move my sites from GoDaddy to one of the hosts where it works the way it’s supposed to. I wish I had a comprehensive list of those, but I don’t. The video mentions Hostgator and Bluehost favorably. I know there are issues with GoDaddy, Dreamhost, and Rackspace Cloud.
If you host your WordPress installation at Hostgator or Bluehost, run-don’t-walk over to the BackupBuddy site and GET THIS PLUGIN. If you don’t, then you might want to wait a few months, or at least check with the sales team before purchasing to find out whether there have been any reports of problems with the hosting company you use. But bookmark the site and keep an eye on it, because this is what WordPress site owners—and especially developers—have been waiting for.