Is there still nobody here who can answer my question?
I'll try... I have a similar configuration, but mine does NOT do estimates for incrementals.
You probably have to add "skip-incr" to the dumptype.
Maybe I found a bug in the source or in the manpage. :-)
I tried to understand the source of planner, and if I succeeded in understanding the source it does something different than the manpage says. (Or my understanding of C is not aligned with my understanding of English.)
See server-src/planner.c: Line 840 evaluates true for your config, and this seems to ask for a level 1 on line 866. AFAIK, there should be a test for "strategy noinc" too, as the man page suggests, or the wording in the manpage is wrong.
865 else if(curr_level == 0) {
866 askfor(ep, i++, 1, &info);
867 }should be something like:
865 else if(curr_level == 0 && dp->strategy != DS_NOINC) {
866 askfor(ep, i++, 1, &info);
867 }I'll have to study it more carefully if this is indeed the right solution.
dumpcycle 1 day runspercycle 5
I have this as:
dumpcycle 0 days runspersycle 1
but your dumpcycle gets overruled in the dumptype anyway. Your runspercycle is a little bogus, but I would not expect that to introduce estimates for incrementals either.
define dumptype always-full { global comment "Full dump of this filesystem always" compress none priority high dumpcycle 0 strategy noinc }
My dumptype is:
define dumptype allways-full {
program "GNUTAR"
index yes
record no
compress client fast
dumpcycle 0
skip-incr yes # emphasize we only want full dumps
strategy noinc # also reduce time to do estimates
}And, as said, my config does NOT do estimate for incremental levels.
By the way, even though the above specifies:
etimeout 300 # number of seconds per filesystem for estimates. dtimeout 1800 # number of idle seconds before a dump is aborted.
the estimate is not aborted after 300 seconds but only after 1800 seconds. That doesn't seem right, does it?
The etimeout is multiplied by the amount of disklistentries for that machine. For 6 DLE's on that machine amanda times out after 6*300 sec.
Furthermore, even after the planner decides to timeout and cut the connection, the amandad/sendsize/ufsdump processes keep on running on the client (until they're done, in fact, but they have nowhere to send the data to). Shouldn't they be terminated as well?
The etimeout is not meant to interrupt the client, but to avoid that a crashed client holds up the backup of all the rest. A nice improvement maybe... (I've never feeled the need for this, because I do want the estimate when I ask it, and the rare cases where the timeout goes off, is for real cases, like crashed clients.)
-- Paul Bijnens, Xplanation Tel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUM Fax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *********************************************************************** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, F6, * * quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... * * ... "Are you sure?" ... YES ... Phew ... I'm out * ***********************************************************************
