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 jon AT jgcomp DOT com
JG Computing
4455 Province Line Road (609) 252-0159
Princeton, NJ 08540-4322 (609) 683-7220 (fax)
|
