On Wed, Aug 08, 2007 at 10:10:31AM -0400, Chris Hoogendyk wrote:
>
> > Mitch Collinsworth <mitch AT ccmr.cornell DOT edu> writes:
> >
> >> 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.
>
>
> 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.
I've moved this to the hacker's list rather than user's.
One problem, not unsurmountable, I see is the lack of configuration
information on the client. "I'm here, back me up now" is not sufficient
as the same client host could be in several amanda configs on the server.
And theoretically could be backed up by multiple servers. So I think for
a roaming client, some decentralization of administrivia would be needed.
Assuming that were worked out, some more blue sky thinking ...
Perhaps a first contact could have the roaming client ask for info, like
what DLE's and parameters do you have for me. Are any due for a level 0
and what was the last level. Then perhaps the connection could be dropped
while estimates were made.
After estimates were done, a second connection to say "here are the results,
which should be done, and can you deal with them now (i.e. accept the stream
and store it on the holding disk)?"
Any value in separating the roaming holding disk from the regular hd?
--
Jon H. LaBadie jon AT jgcomp DOT com
JG Computing
4455 Province Line Road (609) 252-0159
Princeton, NJ 08540-4322 (609) 683-7220 (fax)
|
