|
Re: 36-42 hour backups
2008-06-18 20:32:58
FL wrote:
Hi,
My AMANDA 2.6.0p1 installation works--I'm using a Tandberg Magnum 224
LTO3 tape drive.
I can supply the config--is there a way to ensure that runs don't take too long?
That's really a wide open question. You're dealing with the hardware
configuration of your backup server and the machines that are being
backed up, the OS and software configurations, the network, the workload
of other activities, etc. all mixed together. It's a systems performance
tuning problem.
For example, I'm running a Sun E250 with 2G RAM, a pair of 300G SCSI
drives for holding disk space, and a PCI Ultra-320 SCSI card to attach
my AIT5 tape library. As far as an E250 goes, that's pretty optimal and
it's not running anything else besides Amanda that takes resources. I
can drive my tape at maximum speed, but it is idle much of the time
while data is being pulled across the network. I wanted my backups to
run faster, and I figured a GigE card might do the trick. One of the
great advantages of Amanda is that I don't have to run Amanda to do the
tests. It uses native tools, so, as I juggle things, I can test the
native tools before putting it all together with Amanda.
I found if I do an scp (so that's going to be ssh) from the Amanda
server to my desktop over a GigE connection (on a dedicated isolated
switch), I'm only getting maybe 7% of the GigE. Better than 100Mb
connection, but not by leaps and bounds. I did this with a 130G file and
watched top while it was running. The ssh process on the E250 was using
99% of one CPU, and the scp was using 15% of the other CPU. So dig into
that a bit. I discovered that the default encryption used by Sun's
implementation of ssh on Solaris is 3des-cbc, which is slow. I could
change the ssh config to run blowfish and it would be maybe 3 or 4 times
as fast (the encryption -- still have to test overall effect). Or, I can
configure a backside private network that is GigE for backups only and
inaccessable otherwise and then run it without encryption. That would
work in the server room.
The other side of this is that one of the primary servers I have to back
up is running departmental email. It really gets hammered by spam, and
sometimes we have the load running so high that Amanda can barely get a
CPU cycle in edgewise. So we've been working on tuning the email
processing. After doing everything we could possibly think of with
sendmail, we took a chance and turned off spamassassin. Not too bad.
We're hitting most of the spam with other techniques, and the load is
now way down. That helps Amanda a lot.
Some of that may now turn out to be moot, because we got new servers,
and I'm working on setting those up. That will change the whole game.
They are Sun T5220's, and I may be able to move the compression from the
Amanda server to the department server. They may be as much as 100 times
faster than the E250's they are replacing. It will end up being a
completely different juggling act. But I know that whatever resources I
give Amanda, Amanda will do a great job of juggling them. There may be
some configuration tuning there, but I think I have mine all set.
Coming back around to your situation -- fill us in on some of your
details -- how much data are you backing up, how many servers, what sort
of network, a sample report from Amanda, where do you think your
bottlenecks are, etc., and you may get some useful suggestions specific
to your setup. It's possible your Amanda configuration could use some
tuning, but it may also be that your issues are elsewhere.
---------------
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
|
|
|
