Steve Newcomb wrote:
> Mitch Collinsworth <mitch AT ccmr.cornell DOT edu> writes:
>   
>> On Tue, 7 Aug 2007, Dustin J. Mitchell wrote:
>>     
>>> All in all, it sounds like a lot of work, unless this is a months-long
>>> conference :)
>>>       
>
> I agree.  Changing a working backup configuration in order to handle a
> temporarily out-of-town condition is just *not* something I'm willing
> to do.
>   
>> Which is why it would be really nice to have a different triggering method
>> for performing backups on roaming laptops.  Something that begins with the
>> laptop calling in to the server and saying "Yoo-hoo!  I'm over here.  Can
>> you please back me up now?"  Then the server can do the backup to holding
>> disk and then flush to tape next time a regular scheduled <config> run is
>> made.
>>     
>
> This is a nice idea, but, personally, I would be happy simply to
> establish a tunnel through which the backup will be tranmitted later,
> at the usual time, in the usual way.  
>
> In any event, I'm gathering that this is not something that amanda can
> do right now.  Too bad.  It's something for you developers to think
> about, though.


Been kicking this around in my head the last day or so (and at times
previously). My knee jerk reaction has been, "umm, that really doesn't
flow with amanda's operational philosophy." It's true some other backup
software can do it (Retrospect could when I knew it), and it's nice for
those situations. But, for a gazillion reasons, it just doesn't fit in
with amanda's design.

Finally, the light went on, and I think I see how it could be done.

It would only work if the amanda configuration had adequate holding disk
space, since it really is very contrary to amanda philosophy to leave a
tape mounted, positioned at the end, and to keep appending to it the way
some backup software (I won't name) does, and it also doesn't make sense
to waste, say, a whole AIT5 tape just for one, say, incremental for one
laptop.

So, here's the idea. New dump type option: roaming. If amdump runs for
that configuration, and that client is accessable, it gets backed up
normally. If amcheck runs, it won't worry about roaming clients that
cannot be reached, unless they have not been backed up in, say, 5 runs
(configurable). Now, the laptop goes on a trip. It is only going to be
available during a certain window, and that's not the window during
which amanda normally runs. So, the client runs `amdumpnow <config>`. A
configuration file would indicate how to connect to the server. Either
have it open an ssh connection, or connect over an ssh tunnel that the
user opened beforehand. It would connect on the amdumpnow port (either
directly or with port forwarding through the tunnel). Since amanda is
not running on the server at the moment, it would activate the amdumpnow
service through inetd. The application launched by that service would
read the configuration, identify the client, decide whether it needed a
full or incremental (possibly with some special logic for roaming
machines that are remote, possibly testing connection speed and
estimating time for backup), and then do the backup, leaving the pieces
on the holding disk. When the official amdump run occurred at some later
time, it would simply pick up the pieces and flush them to tape along
with everything else for that dump. The amdumpnow would result in an
email status report just like a regular run of amdump.

Sounds workable to me.




---------------

Chris Hoogendyk

-
   O__  ---- Systems Administrator
  c/ /'_ --- Biology & Geology Departments
 (*) \(*) -- 140 Morrill Science Center
~~~~~~~~~~ - University of Massachusetts, Amherst 

<hoogendyk AT bio.umass DOT edu>

--------------- 

Erdös 4