ec2-manage-snapshots

Based on code from Oren Solomianik’s ec2-delete-old-snapshots ec2-manage-snapshots does things a little differently.

Oren’s script would delete any snapshots older than n days for (a) given volume(s). I improved the code a little bit so as to handle a –region parameter ( –region eu-west-1 is an example) an –noop so as to tell us what it would do but not actually do it. That’s the ec2-delete-old-snapshots you’ll find in the included archive.

Because I wanted to manage snapshots differently I heavily modified the original script to create ec2-manage-snapshots so that for a given volumes, it would keep snapshots made:

  • in the last 7 days
  • the past 4 sundays
  • every first day of the month

and erase the rest.

Its behavior can be easily modified but I wanted to make sure I kept monthly snapshots, last 4 weekly & last 7 days worth. It assumes you’re doing one daily snapshot of each volume.

Download here: ec2-manage-snapshots

Failsafe
Like its ancestor, the program checks to see that each vol-id entered on the command line has at least one newer snapshot than the deletion date, to prevent deletion of all snapshots of a certain volume. The deletion process will commence for a volume only if such a snapshot was found. More importantly, you can use the --noop command line option or the constant in the code (NOOP) and the script will tell you what it would have deleted but won’t actually delete anything.

Disclaimer: This program is in development. Although it has been tested and worked on production environments, it can’t be guaranteed to perform without unexpected results. Use at your own risk.

Amazon Cloud: so you don’t have to optimize your code

When I joined ‘V’, one of the products I am managing had huge performance issues. As the tool had became popular, the database-heavy code had caused the application and its servers to collapse onto itself. Since the product is a classic LAMP application, a decision had been made, rushed, to move everything to AWS and use a huge RDS instance for the database.

Let me pause for a second. What’s RDS ? Relational Data Service is a product from the good folks at Amazon, an implementation of MySQL as a service (as opposed to renting a virtual machine instance and installing MySQL 5.x on it). I like that approach since it frees us from having to

  • install security fixes to the OS,
  • bug fixes to the database engine,
  • back-up the database (mostly)
  • and other administrative chores.

The downside is minimal:

  • Price, a RDS instance is slightly more expensive than an EC2 instance with MySQL on it
  • RDS does not _yet_ support some features that we might want to use down the line (Replication, myisampack, …)

Now of course moving to an extra large RDS instance, the modern version of ‘throw hardware at the problem’, did not solve our performance issue. The dev team has been hard at work optimizing the application, getting pretty incredible performance improvements in the process. While they’re doing that, I am working on putting the right AWS based cluster in place to host the application for now and the future.

More on that later.