Code V.igoro.us

In the second installment a series of posts about recent work on Amanda.

The Application API allows Amanda to back up "structured" data -- data that cannot be handled well by 'dump' or 'tar'. Most databases fall into this category, and with the 3.1 release, Amanda ships with ampgsql, which supports backing up Postgres databases using the software's point-in-time recovery mechanism.

The how-to for this application is on the Amanda wiki.

Yesterday, March 24, was Ada Lovelace Day. I was at Pumping Station: One, and decided to spend an hour or so writing something to honor the first computer programmer. I was feeling singularly uninspired, and googling for "Ada Lovelace" didn't turn up anything interesting. But it did give me an idea: write a program that googles for you!

I'll be giving a presentation about Twisted Python programming tomorrow at Pumping Station: One in Chicago. If you're in the area, you should come by!

• 8pm (doors at 7) at 3354 N Elston
• Advance copy of the Presentation
• Video (available after the talk is complete)

I don't write about it here, but I've been getting into brewing beer. I downloaded an app for my iPhone, iBrewMaster, which helps me store recipes and track batches of homebrew through the brewing, fermeting, and serving stages.

I recently decided to make a clone of Dogfish Head's Raison D'être. This beer is fantastic, but that's beside the point. I added the recipe to the app, and clicked save. In the menu, however, I saw "Raison D'√™tre". Not pretty. The app has a feature where you create a "batch" from a particular recipe. I did so, and the name of the batch appeared as "Raison D'‚àö‚Ñ¢tre". Even worse!

Amanda's primary mission in life is to move large quantities of data around. Historically, this has been done through a patchwork of methods, each written separately and with its own quirks. POSIX pipes, TCP sockets, shared memory, on-disk cache files -- Amanda's done it all. But these multiple implementations were error-prone, difficult to maintain, and often not the most efficient approach.

In an effort to remedy this, we introduced the transfer architecture, abbreviated XFA. This was technically included in Amanda-2.6.1, but was only used by amvault. In the upcoming Amanda-3.1 release, however, the XFA is central to all recovery operations, and is used internally by the taper (the portion of the backup system that writes to devices).

This post highlights some of the features of the transfer architecture, and some of the improvements we'd like to make.

This is the first in what will be a series of posts about recent work on Amanda. Amanda has a reputation as old and crusty -- not so! Hopefully this series will help to illustrate some of the new features we've completed, and what's coming up. I'll be cross-posting these on the Zmanda Team Blog too.

Among open-source applications, Amanda is known for being stable and highly reliable. To ensure that Amanda lives up to this reputation, we've constructed an automated testing framework (using Buildbot) that runs on every commit. I'll give some of the technical details after the jump, but I think the numbers speak for themselves. The latest release of Amanda (which will soon be 3.1.0) has 2936 tests!

These tests range from highly-focused unit tests, for example to ensure that all of Amanda's spellings of "true" are parsed correctly, all the way up to full integration: runs of amdump and the recovery applications.