Steve Newcomb wrote: > Mitch Collinsworth <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> --------------- Erdös 4