[prev in list] [next in list] [prev in thread] [next in thread] 

List:       amanda-hackers
Subject:    Re: Hypothetical AMANDA setup - any comments?
From:       Rob Jenson <rbj () disaster ! gsfc ! nasa ! gov>
Date:       1995-07-24 0:25:44
[Download RAW message or body]

George,

	I second the need for a 'latest-start' parameter in
the next release of AMANDA (which is why I sent this
reply to amanda-hackers instead of amanda-users)... Our
transition from 2.1.1 to 2.2.6 has led to some 4-hour dumps
going to 11, 12, 13-hour dumps depending on the network and
sizes.  It's not really AMANDA's fault, it's the switch
do that as quickly.

	Since there is no way to stop AMANDA (short of killing
her manually), we need a way to have 'planner' stop spawning
dumper processes after a certain time (on the server).  My
users get really nasty if they get in to work and find this
user 'amanda' chewing up all their CPU when they want to chew
it for breakfast doing data analysis.

	The short term solution is to either remove the 'compress-fast'
option from your larger filesystems, or get some more tape drives.
Another possible problem is how your tape servers are configured
in relation to your clients on your network(s).  We made things
much better for all the AMANDA processes by localizing a few
tape drives on the same subnet as the client, (or, more true
to the current "architecture" here, behind the same bridge).  All I
can add is that 'not being able to reliably back up all the machines
every night' has usually been good enough to get someone to squeeze
out the $$$ for more tape drives.

_rob_
>...From the mail of George M. Weaver:
>
> We have 273 filesystems totalling more than 170 GB that I back up to 2
> EXB-8500's nightly with Amanda 2.2.6.  The only comment I would make is
> that dumps sometimes run *much* longer than usual, resulting in Amanda
> still running during the day and increasing the chances of an unrestorable
> dump file.  (Not to mention the additional load on the dump host and
> target machines while people are trying to get work done.)  I have yet
> to discover a way to improve this - some sort of deadline beyond which
> no more dumps would start seems like the right answer.  (These would
> get picked up the following night.)
>
>     -George Weaver
>      Computing Facilities Manager
>      Department of Astronomy and Astrophysics
>      The Pennsylvania State University
>


--
Rob Jenson, Code 664 Systems and Network Administrator
Hughes STX Corp. @ NASA GSFC Lab for High Energy Astrophysics
E-mail: rbj@disaster.gsfc.nasa.gov; Phone V:(301)2863016 FAX:(301)2861684
LHEA SYSTEMS HELP DESK: (301) 286-3692 or mail to system@lheamail.gsfc.nasa.gov
Snailmail: Code 664 Bldg 2 Rm W230K, NASA/GSFC, Greenbelt,MD,20771
....Save electrons and my sanity...Send E-mail instead of telephoning!

[prev in list] [next in list] [prev in thread] [next in thread]