Sorry for the delay...I could not get access to the backup machine last week...

> > [...] sometimes although I get a "finished"
> > report on all DLEs using amcheck, the automatically mailed report would
> still
> > indicate errors of backing up some of the disk entries.
>
> Are you by any chance running into data timeout issues?  Citing the

I think you are right -- a full dump of our machines takes over 20 hours!


> relevant lines for a failed DLE from one of your amanda report mails
> would be helpful.  That would essentially mean that your GNU tar dump
> breaks off at a certain point, and would give rise more or less to the
> symptoms you describe.
Here is an excerpt (I hope I have included the helpful lines).
So from the following backup run, I had difficulties accessing *some* of the
files on the first two DLEs on mac1, and all of mac2 (which is more obvious
why)....
=========================
----- snip ----
  planner: Adding new disk mac1:/home/DATA/macGoNoGo/.
  planner: Adding new disk mac1:/home/DATA/VisualSearch/.
  planner: Adding new disk mac1:/mnt/winData_fMRI.
-----snip---
  driver: mac2 /home_USERS 0 [dump to tape failed, will try again]
  driver: mac2 /home_BACKUP 0 [dump to tape failed, will try again]
-----snip---
DUMP SUMMARY:
                                     DUMPER STATS            TAPER STATS
HOSTNAME     DISK        L ORIG-KB OUT-KB COMP% MMM:SS  KB/s MMM:SS  KB/s
-------------------------- --------------------------------- ------------
mac1        -macGoNoGo/ 0 2523264017034706  67.5  31:478935.0  31:478934.1
mac1        -ualSearch/ 0 1908398011549525  60.5  22:088695.5  22:088695.3
mac1        -nData_fMRI 0  475000 121747  25.6   0:313938.0   0:313935.5
mac2        -ome_BACKUP 0 9549831293783744  98.2 203:137691.3 203:157690.6
mac2        /home_USERS 0 FAILED ---------------------------------------
------snip--
===============


> Actually, indexes are files on Amanda server, in a directory specified
> by 'indexdir' parameter in amanda.conf. Look into these index files to
> see if they list all the files that they should.
Ah, okay. Yes, it seems like sometimes the files that I can't recover are
listed, but they may be files that I can see during amrecover, but when I try
to extract them I get the message:

========
EOF, check amidxtaped.<timestamp>.debug file on localhost.
amrecover: short block 0 bytes
UNKNOWN file
amrecover: Can't read file header
extract_list - child returned non-zero status: 1
========

I'm sorry I am not certain about whether the files are listed in indexdir for
the case when I can't see files during amrecover that should be there (I don't
seem to be able to pinpoint the same problem I had earlier, and I've run a few
more backups since). I assume this usually corresponds to the case when the
files are also missing from the index files?

> The 'quite recent' version of tar may very well be a culprit. There was
> a discussion on this topic on the list recently and it was found that
> several versions of tar, such as 1.13.9x and 1.14.x are not very well
> compatible with Amanda. Versions 1.13.19 and 1.13.25 are the ones that
> are traditionally recommended on this list, also no problems have been
> found with version 1.15.1.

eek...I just checked...the version I have installed is GNU tar 1.13.93.
It seems to work half the time, though...so you suggest I downgrade?

Thanks so much for all you guys' help!!