->>In response to your message<<-
  --received from Nick Pierpoint--
>
> On Sat, 14 Oct 2006 00:17:14 +0100, Nick Pierpoint wrote:
> 
> > On Fri, 13 Oct 2006 14:57:05 +0200, Geert Uytterhoeven wrote:
> > 
> >> On Fri, 13 Oct 2006, Paul Bijnens wrote:
> >>> On 2006-10-13 14:21, Nick Pierpoint wrote:
> >>> > FAILED AND STRANGE DUMP DETAILS:
> >>> > 
> >>> > /--  rollins /home lev 1 FAILED [/bin/tar returned 2]
> >>> > sendbackup: start [rollins:/home level 1]
> >>> > sendbackup: info BACKUP=/bin/tar
> >>> > sendbackup: info RECOVER_CMD=/usr/bin/gzip -dc |/bin/tar -f... -
> >>> > sendbackup: info COMPRESS_SUFFIX=.gz
> >>> > sendbackup: info end
> >>> > ? gtar: /var/lib/amanda/gnutar-lists/rollins_home_1.new:1: Invalid time 
> >>> > stamp
> >>> > ? gtar: /var/lib/amanda/gnutar-lists/rollins_home_1.new:2: Invalid 
> >>> > inode number
> >>> > | gtar: ./nick/.evolution/cache/tmp/spamd-socket-path-M7CcHJ: socket 
> >>> > ignored
> >>> > | Total bytes written: 7639367680 (7.2GiB, 7.1MiB/s)
> >>> > ? gtar: Error exit delayed from previous errors
> >>> > sendbackup: error [/bin/tar returned 2]
> >>> > \--------
> >>> 
> >>> 
> >>> I believe you have a problem with the filesystem that holds /var.
> >>> Is it full?  Or is it corrupt? ...
> >>> 
> >>> Gnutar creates a file in the directory /var/lib/amanda/gnutar-lists
> >>> for its listed-incremental feature.  And accessing that file somehow
> >>> triggers the errors "Invalid time stamp" and "Invalid inode number".
> >>> Maybe because /home is larger, and thus while backing up /home the
> >>> error occurs, while backing up /etc, the listed-incremental file is
> >>> much smaller, and does not trigger the error.
> >> 
> >> Have you recently upgraded tar to 1.15?
> >> 
> >> Gr{oetje,eeting}s,
> >> 
> > 
> > I think I started off with 1.15, but recent yum activity in my Fedora 5
> > installation is:
> > 
> > Sep 09 06:06:31 Updated: tar.i386 1.15.90-2.FC5
> > Sep 15 04:16:45 Updated: tar.i386 1.15.91-1.FC5
> > Sep 30 05:20:58 Updated: tar.i386 2:1.15.1-14.FC5
> > Oct 03 05:16:58 Updated: tar.i386 2:1.15.1-15.FC5
> > Oct 11 05:04:54 Updated: tar.i386 2:1.15.1-16.FC5
> > 
> > I ran fsck on the filesystem and there were no problems. I also ran the
> > tar command on its own and it completed ok so it would appear to be the
> > amanda/tar combination that is the problem.
> > 
> > I have deleted the gnutar files associated with the /home backup in
> > /var/lib/amanda/gnutar-lists and this has at least given me a new full
> > backup to set my mind at ease before the weekend.
> > 
> > I'll monitor the incrementals over the weekend and see if the underlying
> > issue remains.
> > 
> > Thanks everyone for your advice so far.
> 
> Well last night's incremental seemed to work ok so perhaps now that the
> gnutar-lists have been re-created the amanda/tar inconsistency is
> removed.
> 
> DUMP SUMMARY:
>                                      DUMPER STATS            TAPER STATS 
> HOSTNAME     DISK        L ORIG-MB OUT-MB COMP% MMM:SS  KB/s MMM:SS  KB/s
> -------------------------- --------------------------------- ------------
> coltrane     /etc        0      82     13  15.8   0:23 577.4   0:0040364.5
> coltrane     /home       0      15     13  87.0   0:091556.4   0:027510.6
> rollins      /etc        0      84     15  17.5   0:20 755.2   0:027262.2
> rollins      /home       2     466    207  44.5   0:534038.1   0:346176.6
> 
> (brought to you by Amanda version 2.4.5p1)
> 
> 

What's the effect of removing these files?  Wouldn't it essentially
cause everything on that partition to be backed up again even though it
is an incremental backup?  This is what I would expect but I'm guessing
this must not be the case as forcing a level 0 would seem to be a
better option at that point if this were true.