>I'm
>using the 'starttime' dumptype parameter to delay one dump to sort of force it
> to be the last one. That's because I want to backup the amanda database and t
>ar snapshot files to the same tape (with indexing turned off) to keep it all t
>ogether in one place (or rather tapes ;-) for easy restoring ...
By "tar snapshot files" are you talking about the index files used
with amrecover?
(btw, the online
>chapter of the unix backup & restore book states incorrectly that this 'startt
>ime' is relative to the amdump start time, but I think I'm not the first one t
>o stumble over it).
Thanks for mentioning that. I'm in the process of reviewing those pages
and will get this fixed.
>As far as I understand it (and could verify it with the help of the sources) ...
What??? You actually read the sources to see how it worked??? :-) :-)
>this is the designed behaviour ... Is this correct ...
Yes, you've got a pretty good handle on how dumps are ordered.
>is there any other
> trick/configuration/whatever that helps me achieve my goal ?
Not that I can think of without a bit of hacking on the sources.
Eventually, the infamous "taper rewrite" will add the ability to write
special files both at the beginning and end of a tape, which will do
what you want, but that's still a long ways off.
One idea that pops to mind is to insert a script of your own in the
planner -> driver pipeline in the amdump script. The backup schedule is
plain text and is easily altered (you can see it in the amdump.<NN> file).
However, tricking driver into doing what is desired can be harder.
Here's what a typical dump schedule line looks like:
gandalf.cc.purdue.edu /work 1 2 2001:3:21:4:47:48 89 3
The first and second fields are obviously the client and disk. The next
field ("1") is a priority. Don't get your hopes up -- it won't help :-).
The next four fields are the dump level ("2"), time of the last backup,
estimated size in KBytes and estimated time. If this is a level 0,
a second set of four fields may appear to tell driver what to do in
degraded mode.
You might try changing the estimated size and time of just your special
"disk" (the one you want at the end) and crank it the values **way**
up, e.g. to something like a size of 100000000 (100 GBytes) and time of
100000 (over 24 hours). This should cause driver to not try and run
it through the holding disk and delay until the direct to tape pass.
Assuming the numbers are larger than anything else you have, it should
be the last one processed at that time.
Maybe. :-) I'm just guessing here.
Another thought that would involve a little C coding would be to define a
new priority number, e.g. -1000, and then special case that in driver to:
a) put it at the end of the list in sort_by_time (do this code first):
if(sched(a)->priority == DO_LAST_PRIORITY) {
return 1;
} else if(sched(b)->priority == DO_LAST_PRIORITY) {
return -1;
}
b) consider it as IDLE_NO_DISKSPACE by putting this right after the
IDLE_NO_BANDWIDTH test:
} else if(sched(diskp)->priority == DO_LAST_PRIORITY)
cur_idle = max(cur_idle, IDLE_NO_DISKSPACE);
I think that's all it would take. By the time the code gets to doing
the direct to tape stuff, it works strictly in queue order.
Another possibility would be to create a "do this last" queue (based
on the special priority number) and build it in read_schedline() just
like the regular queue, then do the direct to tape loop twice, once with
runq to flush it out as it does now, then again with the new queue to
take care of the remainder. This is a little cleaner since you don't
have to alter a sort routine and the start_some_dump() selection code
is also not changed (it will never see the new queue).
You don't need to change the code that parses the config file. The
"priority" keyword can already handle a number as an argument.
Note: I have not come even close to testing any of this. It's all
speculation.
>Urban
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
