On Thu April 24 2003 03:41, Jeroen Heijungs wrote:
>At 12:23 23-04-03 -0400, Gene wrote:
> >To allow amanda to have a good view of the tape, and because
> > gzip can compress better than the hardware, sometimes by large
> > amounts, its generally recommended the drives compressor be
> > shut off permanently by this group.  It less amanda hassle in
> > the long view.
>
>It was recommended to me to NOT use software compression, with
>the following reason:
>
>"If a software compressed file is damaged, the complete file/tape
> is not readable anymore and therefore useless. If it is NOT
> compressed the rest of the tape/file may be readable, and
> therefore probably restorable."

This isn't smething I've observed.  With the file structure on the 
tape consisting of a tape id header of 32k, a file header of 32k, 
which describes the file in plain english plus howto recover it, 
followed by the file itself, repeating last two steps for each 
entry in the disklist, its quite well laid out and the 2 bare metal 
recoveries I've done here were without incident.  While its 
possible that a gzipped file could be damaged by a tape error, IMHO 
the file is going to be damaged by that same tape error even if it 
wasn't compressed.

>I have never had the opportunity to test this, does anyone has
> some thoughts and/or comments on this?
>I now use the hardware compression, and not the software
> compression, the tapes are big enough, so there is no real
> problem for the time being.
>
As long as the tapes are big enough, its not a problem, but you 
usually have to tell amanda the tapes are 15 to 20% smaller than 
the propaganda claims because while you /etc dir may compress very 
well, that dir full of archive or music is going to expand in the 
hardware compressor, as that sort of stuff has already been 
smunched and isn't further compressible.

Useing gzip, and the uncompressed tape capacity often gets you 
surpriseing results.  From last nights run (I have a DDS2 changer):
------------
These dumps were to tape DailySet1-26.
The next tape Amanda expects to use is: DailySet1-27.


STATISTICS:
                          Total       Full      Daily
                        --------   --------   --------
Estimate Time (hrs:min)    0:28
Run Time (hrs:min)         4:00
Dump Time (hrs:min)        1:41       1:28       0:13
Output Size (meg)        3186.8     3000.7      186.1
Original Size (meg)      9166.6     8785.4      381.2
Avg Compressed Size (%)    33.9       34.0       32.4   
(level:#disks ...)
Filesystems Dumped           37         10         27   (1:26 3:1)
Avg Dump Rate (k/s)       540.6      582.6      249.9
--------------
The hardware compressor cannot match that.  That was a mixed bag of 
both straight, and gzip compressed entries in the disklist.  And I 
had about 600 megs worth of tape left as I run it a bit small to 
assure room on the end for a seperate, non-amanda done, 
uncompressed tarball of tonights indices and the configs that were 
used.  Its part of the wrapper script that runs amdump.  That 
typically appends about 60 megs to the tape, but its insurance to 
me in that if I have to do a bare metal recovery, I can do an seod, 
then backup two filemarks and 'dd' recover the configs and indices 
first, thereby simplifying the rest of the recovery.

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.26% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.