>I have a couple of machines that are slow and poorly connected to my
>tape server. In every instance, I happen to *know* that if these
>machines were to appear first in the backup schedule, the backup would
>finish more quickly.
>
>Is there a way I can push them to the front?
That's harder than you might think.
Planner generates the list of what to do based on size, requests for
special service (forced full dumps, etc) and so on. That's a text "file"
with one line per disk piped into driver.
Driver takes that list and builds a queue of disks to process. That
queue is sorted by estimated dump time (which is based on historical
information, etc), shortest time first (see read_schedule()). When driver
is looking for something to do (see start_some_dumps()), it scans the
list in that order. Planner is the one that estimates the time needed
and passes that (see below).
But note that driver may skip over entries and come back to them later
based on other criteria, such as already having maxdumps backups going
on to that client, bandwidth, spindle contention, and so on.
So the obvious idea of sticking a filter between planner and driver and
having it adjust (lie about :-) the estimated times should re-order the
queue, but it may not do exactly what you want depending on a lot of
other factors.
You can see the lines planner generates in the "GENERATING SCHEDULE"
section of an amdump.<NN> file. Here's a sample broken into multiple
lines and formatted slightly to ease discussion:
fortress.cc.purdue.edu / 1 \
0 1970:1:1:0:0:0 597618 182 \
1 2001:2:12:4:43:9 24681 35
The first three fields say this is a dump of "/" on fortress.cc and
if we have to drop into degraded mode, the priority should be "1".
Note that "priority" is only used in degraded mode -- don't get your
hopes up for an easy fix :-).
The next four fields say a level 0 based at "1970:1:1:0:0:0" is estimated
to need 597618 KBytes and take 182 seconds. The next/last four fields
say a level 1 based at "2001:2:12:4:43:9" will need 24681 KBytes and take
35 seconds. The first four fields are what planner wants driver to do.
The second four fields are optional and tell driver what to do if it
falls back to degraded mode.
It shouldn't be too hard to slip a little perl or awk between planner and
driver (it's literally a simple pipeline in the amdump script) to tweak
the values. And you can test the script with what you see in amdump.<NN>.
The only question is whether it ends up doing what you want.
Harder would be going into driver and coming up with some other way of
deciding what to do next (start_some_dumps()) in a way that did not make
matters worse.
I don't think the estimated time is used by Amanda other than to order
the initial list, i.e. it's not saved in the database. Rather, the
actual results are saved for the next planner run to base its work on.
>Ben
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
