The other night, a number of incremental dumps included a lot of files that
should not have been dumped.

As a result, I got a number of 'dumps way too big' failure messages
causing a number of DLEs to not get dumped since the planner decided
there was no room.

For example, I have a old file, foo, somewhere under directory /xxx...

stat -x foo
  File: "foo"
  Size: 296422       FileType: Regular File
  Mode: (0444/-r--r--r--)         Uid: (  631/     nrg)  Gid: ( 2005/     web)
Device: 0,86   Inode: 28006660    Links: 1
Access: Tue Sep 25 06:29:20 2007
Modify: Mon Feb 23 14:34:18 2004
Change: Mon Sep 17 15:04:20 2007

zgrep foo index/host/_xxx_4.gz
foo

and from /tmp/amanda/sendbackup.20070925052340.debug on the client...

sendbackup-gnutar: time 0.433: doing level 4 dump as listed-incremental from 
/local/backup/amanda/gnutar-lists/xxx_3 to 
/local/backup/amanda/gnutar-lists/xxx_4.new
sendbackup-gnutar: time 0.477: doing level 4 dump from date: 2007-09-18  
9:31:24 GMT
sendbackup: time 0.530: spawning /site/dist/amanda-2.4.5/libexec/runtar in 
pipeline
sendbackup: argument list: gtar --create --file - --directory /xxx 
--one-file-system --listed-incremental 
/local/backup/amanda/gnutar-lists/xxx_4.new --sparse --ignore-failed-read 
--totals --exclude-from /tmp/amanda/sendbackup._xxx.20070925052341.exclude .

grep xxx.3 /etc/amandates
/r/cvs 3 1190107884

env TZ=GMT date -r 1190107884
Tue Sep 18 09:31:24 GMT 2007

This matches debug output above, and is well beyond the mtime of the
file in question: Feb 23, 2004.

head -1 gnutar-lists/xxx_3
1190113536

gtar 1.15.1
amanda 2.4.5

 From the above debug, it looks like amanda is doing the right thing.

The only thing I can think of is an obscure gtar bug that doesn't work
with certain dates, or the date at the top of xxx_4.new (used by
--listed-incremental I believe) was somehow wrong after it got copied
from xxx_3.  There were no 'filesystem full' problems.

Before last night, it did 7 nights at level 4 with no such problems.
Last night, it pretty much did a level 0 as far as I can see (the
index file looks like it has every file under /xxx) even though it
claimed to be doing a level 4.

Some files did change under /xxx, but the vast majority did not and
still got dumped by gtar.

The estimate was way too big, too...
planner: time 12274.025: got result for host yiff disk /xxx: 0 -> 9389110K, 4 
-> 9389100K, -1 -> -2K

Has anyone else ever seen this behavior?