Backing Up a Bitnami WordPress Stack on an AWS Micro Instance

If you follow me, you know that I am quite enamored with Amazon’s EC2.  Scalable, reliable, powerful, and cheap – it’s a revolution in computing.

The smallest and least expensive EC2 instance is the Micro instance.  It’s perfect for a light-duty web server: it has low memory and CPU capability but is capable of bursting to two processors, giving it responsiveness when you need it.  And Bitnami has the perfect partner for your Micro instance: a WordPress stack customized to live in the cramped space of the Micro instance.

What you get in the package is nice: a complete LAMP stack running on a simplified Ubuntu 10.04 server with WordPress preconfigured and ready to go.  Bitnami conveniently puts the entire stack in a single directory – you can zip that directory and drop it on another server and with very little effort you’re up and running again.

There’s plenty of info on the Bitnami site, so if you’re interested in setting it up, head over and check it out.

Where I was left a bit in the dark was… backups.

My first instinct was to use an S3 rsync tool to sync the Bitnami stack to S3.  There’s S3rsync, but that costs money, and I’m seriously committed to spending the smallest amount of money possible on my web server.  So I passed and instead settled on using S3cmd instead.

Using S3cmd, I was able to write a simple script that performs the following:

  1. It stops the Bitnami stack temporarily (this is acceptable in my application)
  2. It ZIPs the contents of the Bitnami folder to a ZIP file that uses the date as the filename (2011-07-11.zip)
  3. It copies the ZIP file to an S3 bucket
  4. It restarts the server

As a once-a-week backup it worked pretty well.  Backups were a little large, because they contained a full snapshot of the entire stack, but S3 storage is cheap, and it’s nice to have your entire stack in a single backup file.

However, occasionally, the ZIP process would crash the little Micro instance (HT to +Ben Tremblay for first noticing during a heated debate on his Google Plus page).  So I started looking for another solution, and realized there is a much more elegant and powerful option: automated EC2 snapshots.

Turns out there are a number of different ways to skin this cat.  I chose Eric Hammond’s ec2-consistent-snapshot script.  Turns out this was a good choice.

Since the Bitnami Ubuntu 10.04 server was a bare-bones install, a number of prerequisites were missing, notably PERL libraries (DBI and DBD) etc.  Fortunately all of the answers were already available in the comments section of Eric’s web page.  For me, all I needed to do was:

sudo apt-get install make
sudo PERL_MM_USE_DEFAULT=1 cpan Net::Amazon::EC2
sudo apt-get install libc6-dev
cpan -i DBI
cpan -i DBD::mysql

The first time I tried it, it worked.  One line of code – in about 0.8 seconds I had taken a snapshot of my disk.  In no time at all I had installed a CRON job to automatically snapshot my server.

EBS snapshots are always incremental (only the changes since the last snapshot are written to disk) and restore in a flash.  I’ve done a restore and it takes just a few seconds to reinstantiate a machine.  And the actual backup is absurdly gentle on the machine – the script runs in about a second.  Bang! Instant incremental backup.  It’s a miracle.

The script is designed to flush the database and freeze the file system so that the snapshot is performed in a “guaranteed consistent” state.  Unfortunately, to freeze the filesystem, you have to be running XFS, and the Bitnami machine uses While I agree that it is important to quiesce the database prior to snapshotting, I don’t know that it is required to flush the filesystem, since EBS volumes are supposedly “point in time consistent”.  Regardless, my web sites do so little writing to disk that it is inconceivable that my file system would be in an inconsistent state.

In short: *rave*.

Lessons in WordPress Conversions

Over the past few days I’ve been performing a pretty significant WordPress migration for a set of sites that I have been hosting.

The source is a set of individual WordPress sites running on an small Amazon EC2 Windows instance.  I migrated them to a multi-site installation running on a micro EC2 Linux instance.

Over the course of the conversion I learned a variety of lessons.

First, I learned that the WordPress multi-site (“network blog”) feature is still fairly half-baked.  You have to be prepared to get your hands pretty dirty if you want to make it work.

I also learned to really appreciate the Bitnami WordPress Stack AMI.  It allows you to spin up a fully-configured, ready to use Ubuntu LAMP / WP stack onto an EC2 micro instance with a minimum of fretting.

I will update this post with some details of the process for those interested.  In the meantime – success is mine!