Jon,
Georg,
Eric,
In layman's terms, Amanda did take into account the spool capacity
and did perform my largest dump last because the Driver prefers
the smaller/faster dumps to start first, allowing for dumporder,
bandwidth, overdue and additional parameters.
So its was good design that got my other 3 partitions to spool and
tape first. That is good "amanda" design, the defaults worked to my
benifit, good I didn't fool with any of them.
Degraded mode is when files are left in spool (tape is unavailable)
and (may) adjust the dump levels if needed and possible.
I now recall that not using spool and writing directly to tape is
called "writing directly to tape" or "direct to tape".
There are still performance gains in using spool vs direct to tape
especially regarding being able to stream the data to the drive which
(often) results in greater tape utilization (drive dependent).
Thank you for the explainations (I think I get it), I'm not trying to
oversimplify but letting it sink in from the big picture downwards.
If only we'd remembered to up the holding disk size in amanda.conf
yesterday after we'd replaced the spool disk.
thanks,
Brian
> > Planner and driver both contribute, I believe:
> > - Planner offers a suggested ordering (e.g. it gives priority
> > to a DLE that's overdue for a level 0)
> >
> > - Driver determines dynamically which dump(s) it can start at
> > any given time, based on your "dumporder" amanda.conf
> > parameter, the ordering suggested by planner, and on
> > available resources -- holding disk space, network bandwidth,
> > number of dumps already running on that client, etc. (N.B.:
> > Once a dump has been started, it runs flat-out; Amanda does
> > no further throttling.)
>
> Let me emphasize that "dumporder" thingy. The default is to have the
> first 3 dumpers prefer partitions dumping in short time, any additional
> ones to prefer partitions requiering long dump times. This typically
> leads to what Brian experiences: small (fast dumping) partitions are
> dumped first and then taped as soon as possible. Depending on the
> "inparallel" parameter (and available bandwidth, holding disk space) it
> might be, that a large, time consuming, dump is started early too, but,
> as that will take it's time to finish, the first 3 dumpers will dump
> many other small partitions in the meantime.
>
> This default may be specified explicitely as
> dumporder = tttTTTTTTTTTTTTT...
> meaning:
> dumper0 t prefer partitions dumping in short time
> dumper1 t prefer partitions dumping in short time
> dumper2 t prefer partitions dumping in short time
> dumper3 T prefer partitions dumping in long time
> dumper<N> T prefer partitions dumping in long time
>
> Thus, large partitions are typically dumped and taped late, but not
> neccessarily last. For a visual impression of how Amanda operates with
> 'ttTTTTT...' go to
>
> http://www.osgev.de/other/amanda/index.html#dump_00_00004
>
> and scroll up a little bit. You'll see the start of a backup session,
> directly after the estimate phase. Notice dumper0 doing most of the
> small patitions, dumper1 dumping mostly the somewhat larger partitions
> and all other dumpers working on the large partitions. Scroll down
> further to see ever longer dump times.
>
> These decisions are made by the driver, which has control over available
> server resources.
>
> The planner's "generated schedule" (which respects, among others, the
> importance of a backup) is considered by the driver, but the most
> influencing factor seems to be that "dumporder".
>
> regards
>
> Georg
> --
> ___ ___
> | + | |__ Georg Rehfeld Woltmanstr. 12 20097 Hamburg
> |_|_\ |___ georg.rehfeld.nospam AT gmx DOT de +49 (40) 23 53 27 10
>
|
