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:
- It stops the Bitnami stack temporarily (this is acceptable in my application)
- It ZIPs the contents of the Bitnami folder to a ZIP file that uses the date as the filename (2011-07-11.zip)
- It copies the ZIP file to an S3 bucket
- 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*.