Patrick Michael Kane wrote:

If you restore a dump file to disk someplace and run "file" on it,
what type of file does it tell you it is?

Do you mean a "normal" amrestored'ed file, or a "raw" recovery?

Actually, I have examples of both:

#  file fileserv._scanner2_Hoyde.20041008.6
fileserv._scanner2_Hoyde.20041008.6: GNU tar archive

# file fileserv._scanner2_Hoyde.20041006.0

- Toralf

----- Forwarded message from Paul Bijnens <paul.bijnens AT xplanation DOT com> 
-----

From: Paul Bijnens <paul.bijnens AT xplanation DOT com>
To: Toralf Lund <toralf AT procaptura DOT com>
Cc: Amanda Mailing List <amanda-users AT amanda DOT org>
Subject: Re: Multi-Gb dumps using tar + software compression (gzip)?
Date: Wed, 20 Oct 2004 13:59:31 +0200
Message-ID: <41765323.1040804 AT xplanation DOT com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) 
Gecko/20040707

Toralf Lund wrote:

Other possible error sources that I think I have eliminated:

 1. tar version issues - since gzip complains even if I just uncopress
    and send the data to /dev/null, or use the -t option.
 2. Network transfer issues. I get errors even with server
    compression, and I'm assuming gzip would produce consistent output
    even if input data were garbled  due to network problems.
 3. Problems with a specific amanda version. I've tried 2.4.4p1 and
    2.4.4p3. Results are the same.
 4. Problems with a special disk. I've tested more than one, as target
    for "file" dumps as well as holding disk.

5. Hardware errors, e.g. in bad RAM (on a computer without ECC), or
disk controller, or cables.

If one single bit is flipped, then gzip produces complete garbage from

that point on. Maybe you're only seeing it in such large backups with gzip, but it happens (less often) in other cases too.

Any tools available to test the hardware?