->>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.