As Jason has already pointed out, we write a lot about backing things up here—and with good reason: data loss can be devastating, not just to your work but to your general peace of mind. And most of us do a pretty good job of ensuring that our local files are backed up (and many of us are careful to ensure that these backups are redundant and off-site).
But as our work lives move increasingly into the cloud, we need to ensure that those files are backed up as well. Natalie has discussed the importance of having a backup strategy for your cloud-based files, including your Gmail account, your Flickr photos, and your Google Docs—but what about your blog?
Whether you’re blogging through a hosted service or using software you install on a shared server, you should think about how your blog posts are being preserved. Given the promises that hosting services make about keeping your data safe, you might think you’re in the clear, but ProfHacker has one friend who came very close to losing seven years’ worth of blog posts when his hosting provider’s server failed and all the backups failed as well.
The thought of such a loss has made me—well, some might say paranoid; I prefer prudent—and so I’ve instituted a regular backup regime for my blog files. This entails two key parts:
Backing up the files: Julie has discussed ways of making sure that your website’s files are safely backed up. Once a month or so, I use the synchronizing feature of Transmit to be sure that I have an up-to-date local copy of all the files that are stored on my hosting provider’s server. (These files then get further saved through my usual local backup processes.)
This is all well and good, of course, but as Julie noted in the post linked above, the key aspect of the blog’s data isn’t in the files, but in the MySQL database that WordPress, in my case, accesses. So the second part:
Backing up the database: It’s fairly easy to do a MySQL database backup, whether from the command line or from a graphical database administrator like phpMyAdmin, but I really wanted something automated and idiot-proof, so that I wouldn’t have to remember what to do. Enter WP-DB-Backup, a plugin for WordPress, which (as you might guess from the name) backs up the database tables that your WordPress installation uses.
The plugin allows you to save that backup to the server or to email it to yourself, and it lets you do that backup either on demand (by clicking “Backup Now!”) or according to an automated schedule.
I’ve set WP-DB-Backup to email a backup of all of my relevant database tables once a week; I have this sent to my Gmail account, so that I don’t have to worry about file size or filling my mailbox. I’ve set up a filter on Gmail that assigns the “backup” label to these message and automatically archives them; once every couple of months I’ll go through the messages tagged with that label and weed out some of the now-redundant older versions.
This is the best kind of backup system for me: one that I don’t have to think about very much. How about you—do you have systems in place for backing up your blog? I’d be particularly interested to hear from those of you who don’t use WordPress; how are you ensuring that your online writing is safe?
[Image by Flickr user dustout; / Creative Commons licensed]
Follow Profhacker through your favorite RSS reader: 
9 Responses to Backing Up Your WordPress Blog
samplereality - June 22, 2010 at 11:25 am
I’ve used WP-DB-Backup for several years as well, and I’m generally pleased with it. However, I’ll offer a word of warning: absolutely make sure that the emailed backup actually contains a valid attachment. When my web hosting service suffered a cataclysmic crash this past spring, I wasn’t worried at first, since I had been receiving emailed backups generated by WP-DB-Backup. Imagine my horror, then, when I opened up the most recent backup, only to discover that the .sql.gz file was 0 bytes! Something had gone wrong and for several months I had been receiving backups of nothing at all!Upon setting up WP-DB-Backup (or any other automated backup procedure) I strongly recommend opening your first several automatically generated backups and making sure they are valid backups of what you intended to backup. And then check the newest backups at least once a month afterward, to make sure the process is still working fine.Ever since my server crash I’ve also made automatic daily mysql dumps using CRON and a shell script. Redundancy has become my watchword. Anything worth backing up once is worth backing up twice.
kfitz - June 22, 2010 at 12:59 pm
Ooh, thanks for the warning, @samplereality! Redundancy is key, as is making sure that your automated backup systems actually produce viable backups.
bul51902 - June 22, 2010 at 1:12 pm
At times it surprises me that scholars with access to institutional Unix-type accounts and institution-provided data storage are unaware of or unwilling to use venerable, reliable, and no-cost distributed revision control systems like CVS or Subversion for file synchronization and offsite backup.CVS and/or Subversion are routinely maintained on institutional Unix-type accounts, so they cost you nothing (no service fees, no toleration of advertising); one or both are built into OS X (and Cygwin, for Windows users), so it’s not like you have to install anything (beyond Cygwin itself); and it’s really not very hard to set up.The repository is hosted on your institution’s own servers — “offsite,” in relation to your home and/or campus office machines, but not out in a “cloud” with non-guaranteeable privacy and security, which will evaporate the minute the venture capital runs out. And you have the assistance of your institution’s own system administrators (if they’re good), rather than some techie-temp off in yet another cloud.So you get (1) offsite backup, in the repository itself; (2) one-step file synchronization across all your machines, via the repository; (3) version control (with logging, history, analysis, and so on) far superior to anything featured in the word processing and blogging software most academics use. Functions #1 and #2 preserve, protect, and streamline access to one’s data, while function #3 is indispensable for a researcher-writer shaping a lifetime personal-professional archive (http://jofish.com/writing/tohaveandtohold.pdf) of her work.Which we are all doing, whether we are doing it haphazardly, or sensibly and deliberately — right?Several good (and now classic) articles (in multiple redundant copies) on using CVS and Subversion for this purpose:http://www.linuxjournal.com/article/5976http://kitenet.net/~joey/cvshome/http://www.boingboing.net/2003/11/11/cvs-as-a-means-of-ke.htmlhttp://onlamp.com/pub/a/onlamp/2005/01/06/svn_homedir.htmlMany users of CVS and subsequently, Subversion have now moved on to Git. I’m still using CVS, which dates to the 1980s, and I like it fine.As for the specific topic of today’s entry – I don’t blog (or use anything Web 2.0 at all), but if I did, I’d not use any remote service that didn’t permit easy local replication of files.Brian Lennon, Penn State
jmeloni - June 22, 2010 at 3:27 pm
@bul51902 We have written about version control previously at ProfHacker and have several more articles planned for the future (not in the summer) because it is an important topic. The topic of this particular post is backing up a WordPress blog, which — while fundamentally similar (a backup is a backup) — does have some practical differences than backing up work via CVS etc. We hope to see your comments on the actual version control related posts in the future.
george_h_williams - June 22, 2010 at 3:34 pm
@kfitz: I use a WordPress plugin that emails me the backup at regular intervals, but @samplereality’s story has convinced me to doublecheck that I’m actually being sent something!@Brian: Many campuses—mine, for instance— don’t provide much backup storage for their faculty, staff, and students. I think I have a gigabyte on the network, which is great for keeping PowerPoint files for my teaching but which doesn’t provide me with an opportunity to use the network for serious backups. So using networked institutional resources is not an option for many of us. Also, many campuses—again, like mine—do not have a Unix-based network but rather a Windows-based network, so many of us simply don’t have access to institutional Unix-type accounts.
bul51902 - June 22, 2010 at 4:10 pm
@jmeloni – Apologies for a badly placed comment. I don’t look at ProfHacker as often as I would if I’d seen that piece on CVS, SVN, and Git, before — it’s very good. I will join the conversation in a more appropriate place next time.@george_h_williams – Yes, using these depends on access to a Unix account; I’d be very unhappy without it. Re storage: I have access to 2GB, but only use ~650 MB of it, and that’s with an entire copy of all my files checked out into the same disk space as the repository itself, for access through a Web interface (in other words, as storage space counter, that’s two copies of everything). That ~325MB includes everything I’ve written, published, noted, scripted, etc. since 1996, plus eight years’ worth of teaching and ten or so years’ worth of additional research materials. Mostly in text files, though — no data sets, no software, no audio files, no image files apart from snapshots and book/article PDFs. Another habitus might have a larger disk profile, to be sure. -BL
lincolnmullen - June 22, 2010 at 9:47 pm
Thanks for the post, Kathleen.I use WP-DB-Backup to e-mail to GMail too, but now that I’ve seen @samplereality’s comment, I’m definitely going to verify that those backups are useable.I also have a cron job on my server that runs weekly. It backs up everything–server configuration, MySQL databases, and files–in a .tar.gz file that I could upload to cPanel if I needed to restore the backup. I download the backup to my NetGear ReadyNAS Duo every week. Once I figure out how, I’ll create a cron job for the ReadyNAS to download the files automatically. I’m also considering using rsync as another option.The final step in my backup solution is copying everything on the ReadyNAS (which is already a redundant RAID array) to an external hard drive once a month, then storing the hard drive at my university. All that might be a little too heavy duty, but @samplereality’s saga a few months ago scared me.
briancroxall - June 24, 2010 at 3:34 pm
I’ve used the WP-DB-Backup plugin as well, but following a comment from Chad Black (@parezcoydigo on Twitter), I looked into the iDrive Plugin for WordPress. iDrive is a backup service similar to Carbonite, Mozy, or Backblaze. But they’ve take the step to develop a plugin aimed particularly at “providing scheduled as well as immediate backup of WordPress blog data including files and MySQL database dump.” Accounts at iDrive are free for the first 2 GB, so I quickly signed up. I chose not to install the iDrive software as I have other backup plans for my computers. But I downloaded, installed, and started the plugin within 4 minutes. It backs up once a day automatically.
samplereality - June 24, 2010 at 4:57 pm
I seem to have served as a cautionary tale for more than one person! What I learned most from my own experience is that even if you think you are backing up everything, you may not in fact be doing so. I was fortunate enough to run all my sites with a webhosting service that took the loss of customer data very seriously; however, as I was contemplating switching providers, I discovered that none of the big name webhost providers guarantee that your data is protected. Many, in fact, explicitly say that they do not keep regular backups of their clients’ data. All the more reason to do it yourself.