Amanda-Users

Re: tar/gzip problems on restore (CRC error, "Archive contains obsolescentbase-64 headers"...)

2004-10-13 09:49:43
Subject: Re: tar/gzip problems on restore (CRC error, "Archive contains obsolescentbase-64 headers"...)
From: Toralf Lund <toralf AT procaptura DOT com>
To: Amanda Mailing List <amanda-users AT amanda DOT org>
Date: Wed, 13 Oct 2004 15:43:15 +0200
Alexander Jolk wrote:

Toralf Lund wrote:
tar: Skipping to next header
tar: Archive contains obsolescent base-64 headers
37800+0 records in
37800+0 records out

gzip: stdin: invalid compressed data--crc error
tar: Child returned status 1
tar: Error exit delayed from previous errors

I've had the same message from tar on what were apparently erroneous
backups.  I believe the `obsolescent base-64 header' message is what you
get whenever tar's input is corrupted, which seems to be confirmed by
gzip's `crc error'.

I was hoping you wouldn't say that ;-( But yes, I guess it's likely that the actual backup is corrupted.

 I'd venture to say your backups are hosed; if that
arrives systematically, you might want to investigate your SCSI chain.
Well, yes, I've now found that I do get this for different dump files (but not all of them), so I guess some serious problem with the setup is likely. I don't think SCSI-issues is likely to be the cause, though, since I get the same kind of problem with harddisk dumps as well as tapes, and as it now turns out, also for holding disk files. And the disks and tape drive involved aren't even on the same chain.

Actually, I'm starting to suspect that gzip itself is causing the problem. Any known issues, there? The client in question does have a fairly old version, 1.2.4, I think (that's the latest one supplied by SGI, unless they have upgraded it very recently.)

Also, to my great relief, it turned out that I could actually extract most of the files I wanted by skipping over the error point via dd skip=... tar still gave me warnings when I did this (unsurprisingly enough since the data was probably not aligned to a file boundary after the skip), but this time it was actually able to find files after it did. Based on this, I'm thinking that the original tar should at least have been able to resync itself. Any ideas why it didn't?


(Sacrificed a goat lately?)
Apparently not...

- T