Transfer Architecture

From wiki.zmanda.com
Revision as of 17:42, 13 March 2008 by Dustin (talk | contribs) (beginning of documentation)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

The transfer architecture arises from a simple observation about Amanda: its core job is to move data around. Amanda has the Application API, which handles getting data from clients (and returning it on restores); and the Device API, which handles long-term storage of data. The transfer architecture (abbreviated XFA) connects these two APIs.

Overview

At a high level, the XFA is simple. It manages transfers, which are composed of transfer elements. A transfer has a source element, which produces data, a destination element, which consumes it, and zero or more filters, which transform the data that passes through them. Elements send messages to indicate the status of a transfer and record information like index offsets.

Benefits

The transfer architecture has the following benefits:

  • Transfer elements are connected in a maximally efficient manner
  • New elements are easy to add, to support new encryption algorithms, compression utilities, compression offloading, etc.
  • DRY-compliant -- the same code is used in all data transfers, so it is better-tested and error messages are predictable

Conceptual Details

API Details

These articles describe the Perl API to the transfer architecture. The C API is similar, and its use should be clear from the source code.