Dustin J. Mitchell wrote at 14:09 -0500 on Sep 13, 2010: > On Sun, Sep 12, 2010 at 9:36 PM, John Hein <jh...@symmetricom.com> wrote: > > This may not be considered a nitpick but more of a feature request. > > > > If I move a disk or rename a host or move the host to a different > > domain, it'd be nice to be able to rename the disklist entry (DLE) and > > have history tracking, incremental planning, and most importantly > > recover/restore operations off tape know to follow the rename. > > > > Maybe it's as simple as allowing one or more "alternate DLE name" or > > "alias" (if you will) entries in a DLE (note the casual insertion of > > the word "simple" does not imply I have a patch, sorry). > > > > Going back and doing a rename on log files, index files, dump files, > > etc., is, of course, not practical and not really desired in terms of > > representing history of a name change. > > This is an interesting idea, both for the purpose you describe, and > for the very futuristic and don't-get-excited-yet idea of "virtual > DLEs", where Amanda automatically splits DLEs based on size of > subdirectories. The main problem with virtual DLEs has been recovery: > if Amanda is backing up a particular file in a different DLE every > day, then it's going to be difficult to find it when it comes to > running amrecover. Incrementals are also a problem: changing the > boundaries between DLEs obviously requires doing a full backup of all > of the affected DLEs on the next run. At least, unless we're going to > become gnutar-specific and start futzing with the data in the backups > on the server side. > > As you can see, complicated. But a consistent approach to storing the > DLE and path of a particular "user object" over time would be a useful > first step. Do you have any thoughts on how that might be > implemented?
It may be useful to consider having amanda store the disklist it uses with each backup (in the index db) [1]. And that there is some way to correlate the "same" DLE in one disklist that may just have a different hostname (or I suppose filesystem mount point - let's call it a host/filesystem tuple because that sounds fun) to the renamed DLE in another disklist. I suppose we could take a page from revision control design and have a DLE ID (SHA checksum perhaps of the "important" identifying contents of the DLE - that is, not things like maxdumps). And the hefty work for this feature would be to add would be a way to link DLE IDs together and have amanda understand the potential equality between more than one DLE ID for the various history-traversing operations she does. [1] I keep the disklist in revision control anyway since it would need to be consulted to properly restore some data from a year ago that may have moved around. Having amanda handle that tracking would be nice.
