[CLUE-Tech] tar to tape with compression

[djperkins at americanisp.net]

> Greetings.
> 
> My tape drive holds 5 GB compressed data.  To this point, I have not run out 
> of room on the tape during nightly backups.  I use 'tar cvfP ... ' to do the 
> backup (... is the list of files to save).  I use 'tar dvf /dev/st0' to 
> validate the archive.
> 
> Lately, I think I started using all of the space on the tape because I see 
the 
> following in my backup log (which is the stdout of the tar command):
> 
>    tar: /dev/st0: Warning: Cannot close: Input/output error
> 
> So, I thought I should tell tar to use compression.  I tried it on my /etc 
> directory:
> 
> $ tar zcvfP /dev/st0 /etc
> 
> This works, but the corresponding validation command:
> 
> $ tar zdvf /dev/st0
> 
> produces this output:
> 
> 	...
> 	/etc/shadow.bak
> 	/etc/group.bak
> 
> 	gzip: stdin: decompression OK, trailing garbage ignored
> 	/etc/mime.types
> 	/etc/mailcap
> 	/etc/gshadow.lock
> 	/etc/group.lock
> 	tar: Child returned status 2
> 	tar: Error exit delayed from previous errors
> 
> I understand this to mean that tar (by way of gzip?) is padding the archive 
to 
> make an even block size for the tape.  I assume that this is message is 
> innocuous for my purpose of validating the archive.  Is this a correct 
> assumption?
> 
> TIA
> Jeff
> -- 
>     planet earth (tm)
> http://jefferycann.com/
> _______________________________________________
> CLUE-Tech mailing list
> CLUE-Tech at clue.denver.co.us
> http://clue.denver.co.us/mailman/listinfo/clue-tech
> 


I don't recall ever seeing gzip say anything about ignoring trailing garbage.  
And what is error status 2?

Tar should pad the last block, otherwise you probably would not be able to add 
another tarball at the end.

If you want to do compression on your backups, you might want to consider afio 
instead.  Tar compresses the tarball, not individual files, so any error could 
make the backup unreadable.  Afio can compress files individually as it is 
making the archive, so an error detected during decompression should leave the 
other files intact.  I suspect the backup is probably larger but the tradeoff 
might be worth
it.