On Sat, Apr 23, 2005 at 06:44:49PM +0200, Peter Mueller wrote:
> 
> Jon LaBadie wrote:
> 
> >Now, if the estimate had been 24GB, you would have gotten a
> >message in your report about "way too big".  I don't know
> >what the fudge factor is and where amanda considers it too big.
> >
> Thats what confused me. But also amflush tries to put it on tape,
> and at this point, the 12GB > 11.7GB comparison is evident!
> Furthermore, it does not try to put the smaller dumps resting on
> the holding disk, resulting from the follow up amdump at the
> night after the desaster ....

OK, suppose you were one using HW compression.  You have to
approximate the capacity of the tape by guessing how much
your data will be compressed by the tape drive's compressor.
So maybe you 'guess' at 20GB for your DDS-3 tape.  Then assume
that same DLE, not compressed by gzip, were 20.5GB.  Wouldn't
you want to try and see if it might fit because your size was
only a guess and some DLE's would compress a lot, others only
a bit.  There is no one right answer.


> >>Is there any way to execute a command "just before and after" a
> >>"disk" is backuped ? This would be nice to e.g. shut down and start
> >>servers which may change this data inbetween ...
> >>   
> >
> >See above comment on crontab.
> > 
> Not exactly, since there are several DLEs and I would prefer to be
> triggered just before and after the single DLE is touched. Furthermore
> starting and stopping some servers has to be done on the client side
> so being triggered by te amanda client would be easier since the
> triggered code is called on the relevant system allready...
> 
> >Or wrappers.  Replace amdump with a script.  Or replace the backup
> >program(s) you use, gnutar or dump, with a script.
> >
> >If you don't want to turn things off just before dumping,
> >i.e. not during estimates of during dump of other DLE's,
> >you can add code to do that too.
> >
> > if (output device is /dev/null and not the tape device)
> >     this is an estimate, call the backup program itself
> >
> > else if (this is not a DLE of interest)
> >     call the backup program itself
> >
> > else
> >     the action, stop the service, call the backup program,
> >     save the return status, start the service, exit with
> >     the saved status
> > 
> >
> Ok. I think I got it. But does the amanda client honor the PATH
> variable in his environment? This would be a way to replace gnutar
> with a wrapper - its not acceptable on my systems to replace the
> general one since other programs and users need the original ...
> ... seems to be time for some experiments and research.

And for your situation, a case/switch statement based
on the DLE could do doing different things for each.

As to PATH, my preference is to build amanda with the dump
and gnutar paths specified to configure, and I have them
point to dummy names like .../libexec/amgtar.  The amgtar
is a copy or a link to the real gnutar that everyone uses.
Should I have to replace amgtar with a wrapper, no one else
is affected.  It first became important at a site where they
did not want the standard system components changed and
the standard gnutar was not compatible with amanda.  So I had
to download and build a compatible version and called it amgtar.
I've used the amgtar "trick" ever since even if not needed.

-- 
Jon H. LaBadie                  jon AT jgcomp DOT com
 JG Computing
 4455 Province Line Road        (609) 252-0159
 Princeton, NJ  08540-4322      (609) 683-7220 (fax)