On Wed, Sep 26, 2007 at 06:57:11PM -0600, John Hein wrote: > 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. >
mtime is not the timestamp in question, it is ctime. mtime changes when the data is modified. ctime changes when a property of the file changes. the properties include mtime for data modification, but also owner, links, mode, etc. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road (609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
