On Fri, Jun 15, 2007 at 04:23:57PM -0400, Charlie Reitsma wrote:
> As I read through the man pages I am finding hints that it has been thought 
> of. In the amdd man page "This may be used for debugging or to convert from 
> one format to another."
> 
> I began looking at the contents of various directories and files based on 
> comments found in Gene's Amanda Helper scripts. The index is just a list of 
> files contained in the images 
> contained on the the tape. It wouldn't change at all as the images aren't 
> being modified. I couldn't find anything that maps an image file to a 
> particular location on a tape. It 
> appears that the contents of a virtual tape need no further processing before 
> moving them to a real tape. Copying those images onto a tape and moving the 
> index, curinfo and 
> tapelist date to another cycle seems like it might be straightforward. Since 
> all the image sizes are known in advance they might even be reordered more 
> optimally to fit on tape. I 
> didn't like Gene's suggestion that the virtual tape size and the real tape 
> size should be kept the same. We might even choose to put different file 
> systems on different tapes as 
> they may go to different offsite locations for security reasons.
> 
> Restores appear to collect the images associated with a particular file 
> system and give them back to the appropriate program to extract the file(s) 
> requested. That process wouldn't 
> change just because the media changed.
> 
> I'll take a look at the Developer Documentation to continue my exploration.

Charlie --

This sounds like a great project, and I'm excited you're working on it.
Please feel free to consult amanda-hackers with any further technical
questions or musings you might have.

The functionality you're thinking about is a form of hierarchical
storage management, with data migrating between storage media based on
enterprise policies and needs.  It's a kind of functionality that would
be welcome in Amanda, and that has been in the back of most developers'
minds for some time.

The new Device API will be an important step in this direction, since
(among other benefits) it will allow us to treat all storage media the
same way.  With a little reworking, taper can then become a generic data
migration tool.  The major unresolved issues are:
 - policy (how does Amanda know when to migrate what, and where)
 - metadata updates (which you mentioned above)

Device API: http://wiki.zmanda.com/index.php/Device_API

Once the Device API is released, the immediate next step is to treat
holding disk as a device.  This represents Amanda's existing
functionality -- dumping to holding, then spooling to tape -- as a data
migration, opening the door to more complex migrations down the road.

Dustin

-- 
        Dustin J. Mitchell
        Storage Software Engineer, Zmanda, Inc.
        http://www.zmanda.com/