|
Re: amanda tape use strategy
2004-12-07 17:50:49
Paul & Jon - thanks for the tip about using taperalgo. I wasn't aware of
this parameter. Will try it out but I'm not sure how well it will work
for me - I'm only dumping from one client, there are a lot of
filesystems that are large compared to the tape size and there isn't
enough space to keep all the dumps on the holding disk (HD is size of
one tape, total space to be dumped is several tapes worth). I've been
using maxdumps=1 so turning that up might help (but I'm afraid of the
load it will place on the client) as well as playing with dumporder.
Increasing the HD size might also help :-)
I was kind of hoping that the dumper would be smart enough to dump in an
optimal order (the 40GB space, then one of the 55's, then the other 40GB
and then the remaining 55GB in my example from below). Presumably amanda
has all the relevant info since it does a planning stage first. But
while this may be simple in the case of one client and no compression it
could be tricky with multiple clients, differing bandwidths, compression
etc.
According to Paul, I can't avoid the fact that amanda will attempt to
write a file to tape even when it knows there isn't enough space (if
compression is off this should be very clear). A closer look at the man
page confirms this. Oh well.....
Thanks for the responses!
Chris
Paul Bijnens wrote:
Chris Loken wrote:
Apologies if this has come up before. Couldn't find anything relevant.
I'm talking about level 0 dumps (not incrementals). Using ait-3 tapes,
GNUTAR (not linux "dump"), a tape library, 104GB holding disk and
setting runtapes greater than 1 (I need to dump several tapes-worth of
data). NO software or hardware compression. amanda-2.4.4p1-0.3E
Amanda works great for me. These are efficiency questions - not
critical problems.
a) When backing-up multiple disks from a single client, amanda seems
to dump and then write them to tape in order of increasing size. This
can be inefficient. e.g. if you have filesystems that are 40GB, 40GB,
55GB and 55GB and write to 100GB tapes, amanda will use 3 tapes when
the backup would fit on 2 tapes.
b) amanda doesn't seem to know that it will run out of space on a
tape. E.g. if I have two 65GB filesystems to dump to a 100GB tape,
amanda will write the first and then start writing the second one and
keep going until it hits the end of tape. It then puts in the next
tape and rewrites which is great but a lot of time was wasted writing
a file which wasn't going to fit on the first tape. I'm running
amtapetype for myself right now but have been using a tape entry from
the amanda faq that sets "length 108890 mbytes" (but there are two
different ones for the same drive and tape; Sony SDX-700C and AIT-3).
So, my questions are 1) is what I've described above true (seems to be
for me) and 2) is there anything I can do (easily) to change this
behaviour?
Use the parameter "taperalgo largestfit".
But beware of some interaction with dumporder, inparallel and the
taperalgo:
http://marc.theaimsgroup.com/?l=amanda-users&m=106277015010167&w=2
About nr2: you can't change it, but it hurts less when the largestfit
algoritm is applied.
|
|
|
