How to backup your WordPress blog - WordPress Configuration Management

Having worked as a software contractor in the Defense industry for a number of years I quickly picked up on the importance of Configuration Management (CM) and software change control. The value of developing a good configuration management plan was burned into the back of my head very early on in my career.

By managing the changes made to a work product you are able to recreate it from scratch in the event of a failure (such as a loss of a hard disk or virus). Managing change also allows you to revisit various work product “milestones” at different stages in the development lifecycle (e.g. two releases ago). While quite painful at times, CM can benefit all types of software applications (including WordPress).

The problem with WordPress in regards to CM

When I created my first WordPress blog I instantly fell in love with the speed at which you could get a website up and running. I also fell in love with the ability to change the look and feel of my blog with almost no effort (and all from the comfort of my favorite web browser). With “ease of use” also came the ability to trash my entire blog with a single click.

I’m sure many of you have been there; you activated that brand new WordPress theme and then spent the next three days tweaking the code to get it just how you like it. Then during testing you finally notice that one column hanging out of alignment (which has been for the last day and a half without you noticing). You have no idea which change made over the course of the last three days could have caused it and are forced to start over from scratch…maybe you haven’t but I have and it really sucks.

If I would have saved my changes at various “milestones” along the way I would have saved myself from having to start over from scratch. What’s worse was that I made all of those changes on my live “production” server and my readers were watching the mishap unfold right in front of them!

My Solution

With that being said I quickly made a visit to my “CM Happy Place” and decided to approach my blog the same way I would approach developing a piece of software.

Create a development environment.

The first step I took was to set up a local test environment that mimicked my WordPress setup on the web. This might sound like a no-brainer to most but there are many bloggers out there who have never developed a piece of software before or have ever heard of the SDLC. This single step can save you hours of downtime when you decide to make a change or perform an upgrade.

Creating a local development environment entailed the installation of three software components (a Web Server, a Scripting Engine, and a Database). You may have heard of the term LAMP. LAMP stands for Linux (OS), Apache (Web Server), MySQL (Database), and PHP (Scripting Engine). In my case I am running Windows so I went with a WIMP (Windows, IIS, MySQL, and PHP) setup…LOL, how fitting, <Linux users applaud>! Once the software components were installed and configured, I copied all my WordPress files from the production server. Finally I created the WordPress database using a backup of my production database. I will post the trials and tribulations of this endeavor in a later post (it wasn’t without a few bumps let me tell you).

Now that I had a stable development environment (that looked exactly like it did on the web) I could now test any changes locally without impacting my live blog.

Create a source code repository.

Next I set up a source code repository to version any changes made to my blog configuration from this point on. In my case I choose Microsoft Visual SourceSafe as my source control configuration management tool. There are many other packages out there that perform the same function (e.g. Tigris.org Subversion and MKS Source Integrity). If these tools are too complex you could even choose to version your changes manually (using the file system) but I recommend against it.

From there I determined which files and directories needed to be added to my source code repository. For WordPress, not all files in the htdocs directory need to be checked in (as they are never modified after the initial install).

The files that should be checked in are as follows:

htdocs

|____ .htaccess

|____ wp-config.php

|____ wp-content

|____ themes

|____”your theme directory - *.*”

You will also need to check in any files that you modified along the way (e.g. plug-ins or core WordPress files that were hacked). In my case I only modified my theme so I was finished.

That’s about it. From then on, any time you make a change to your theme be sure to check it out before you modify it and check it back in when you move it to your production server. Most tools allow you to add comments when you check in a file so be sure to add a meaningful comment. Comments really help when trying to determine what was changed between versions.

Additional activities

Database Backups
In addition to the steps above I suggest that you also take regular backups of your WordPress database. There are numerous plug-ins that automate database backups but you can always use a tool such as phpMyAdmin to perform backups manually. You may need to request special access from your hosting provider to access phpMyAdmin on your production server.

Misc. File Backups
You will also want to take regular backups of your wp-content/uploads directory. This directory contains all the files/images that you have uploaded over time and will be necessary if you ever need to restore your blog. I choose not to check these files into my source control repository because of the dynamic nature of the directory structure but you may want to do so in lieu of FTP backups.

Helpful Plug-ins
During this endeavor I also decided to develop a WordPress plug-in called TransferTweaks. This plug-in saves changes (made to the header, footer, and sidebar) in the WordPress database instead of the theme file itself. The plug-in will then insert your code in the appropriate part of the page every time a request is parsed. The advantage of this plug-in is that there is no need to reenter your changes when switching to a new theme. Your “tweaks” will always be available to the current theme via script. I am currently using this plug-in on four WordPress blogs and it has proved to be a huge time saver when changing themes!

Conclusion
Hopefully this article has encouraged you to invest some time ensuring your hard work is protected against any future “mishaps”. All of these techniques are not specific to WordPress and can be easily adapted to virtually any blogging platform with a little research. Finally, checking your code into a source control tool such as Microsoft Visual SourceSafe is not a necessity for properly backing up your WordPress blog. You can back up your blog with as little as a simple FTP client if you wish. There is bound to be something I missed along the way…so please let me know and I will add any details that I missed