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?
