Re: Problem configuring full dump

Gertjan van Oosten wrote:

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:  Paul.Bijnens AT xplanation DOT com
***********************************************************************
* 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          *
***********************************************************************