On Sat, Apr 23, 2005 at 04:02:46PM +0200, Peter Mueller wrote:
> Hi!
> 
> I know this matter has been discussed here serveral times before,
> but scanning the archive and reading the online docs I could not
> find answers to my specific problem.
> 
> My situation:
> 
> Due to non-optimal configuration I got into this:
> 
> .) I thought to used software compression only, but maybe
>   the DDS3 tape drive tried to compress the data too.
> 
> .) My tapedrive configuration in amanda.conf is this:
> 
> define tapetype DDS3 {
>    comment "HP C1537A"
>    length 11738 mbytes
>    filemark 392 kbytes
>    speed 1018 kbytes
>    lbl-templ "/etc/amanda/D1/HP-DAT-Elimpex.ps"
> }
> 
>   As I understand it, it specifies only the uncompressed size
>   of DDS3 tapes, which I use...
> 
> .) I managed to produce a DUMP which is of this sice in the
>   holding disk:
> 
> uschi:/silo1/amanda/20050422 # du -ks *
> 12055028        sonja._silo1.0
> 
> .) Amanda dump and flush try to write this to the tape, and
>   fail, because it is too big.
> 
> 
> Ok. It IS TOO BIG, but now my questions:
> 
> .) Why did this dump even got created ?

A 12.1GB dump with a stated tape capacity of 11.7GB.
Not a large difference.  The pre-dump estimates are just that,
estimates.  Plus the capacity is not an 'absolute' number.

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.

> 
> .) How do I remove it - I know I have to split this area to
>   backup it with amanda but I dont want to break the whole system
>   and start from scatch...
> 
Not certain, but probably 'rm' it and then run amcleanup.
Others may chime in here with alternatives.

For the split, you will have to delete the current DLE, or add
some indication to never back it up.  The create two or more
new DLE's.  The new DLE's will have to get level 0 dumps the
first time amanda encounters them.  Perhaps introduce them on
different days.

> 12055028        sonja._silo1.0
You currently have something like:

sonja   /silo1  <some_dumptype>

A way to adjust this could be:

sonja    SILO1_partA    /silo1    {
      include list append ./<some_bigdir>
      include list append ./<another_bigdir>
           ...
      <some_gnutar_dumptype>
}

sonja    SILO1_partB    /silo1    {
      include list append ./<some_bigdir>
      include list append ./<another_bigdir>
           ...
      <some_gnutar_dumptype>
}

    ...

sonja    SILO1_remainder    /silo1    {
      exclude list append ./<one of the includes from above>
      exclude list append ./<another_include>
           ...
      <some_gnutar_dumptype>
}

You could simplify administration a tiny bit by putting
each partial "include list" in a file (change the above
to "include file xxx") and using the same files for the
remainder "exclude list".

> .) What about this switching DDSx DAT tapes from compressed to
>   uncompressed ? Somebody mentioned a script I cant find.
> 
Do you have reason to believe your tapes have already been
written with hardware compression turned on?  That is the
time it is needed.

Look for past-postings by Gene Heskett for the script.

> .) Is there any way to insert a command in amanda that is executed
>   "just before the tape is accessed" e.g. to switch the drive
>   to uncompressed ?

Yes, several ways.  Your crontab entry can call two cmds (or more)
with one being the appropriate mt cmd before amdump.  Of the one
command could be a shell script that does what you want and then
calls amdump.

The problem with tapes previously recorded with compression on
is that amanda first reads the tape to confirm that it is an
"amanda tape".  During this read, the drive auto-detects the 
compression state and switches to compression on.  And there
is no way to stick in command to turn it off after that.

This used to puzzle me as it never was a problem for me.  Then
I realized that on Solaris, compression is controlled not by
a command, but by opening different devices, some for on and
others for off.  So when amanda opens it for reading, it is
turned off during opening and the drive intelligently switches
to read the compressed data.  But later, when amanda opens it
again for writing, the opening of the device again switches it
off.  Linux's scheme does not supply separate devices like this.

> 
> .) Why does amanda produce "empty" tapes if a dump is too big ?
>   It would be nice if the tape would be at least be reused for the
>   other dumps waiting to get taped ...
> 
Thinking it "might just fit" (only a bit too big) amanda writes
as much as it can, hits the end and fails.  Since there is not a
"complete" dump on the tape, that part of the tape is "wasted".

> 
> And now to something completely different:
> 
> 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.

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


-- 
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)