Amanda-Users

Re: Problems with Incremental Backups

2005-08-11 13:08:31
Subject: Re: Problems with Incremental Backups
From: Jon LaBadie <jon AT jgcomp DOT com>
To: amanda-users AT amanda DOT org
Date: Thu, 11 Aug 2005 11:53:07 -0400
On Thu, Aug 11, 2005 at 10:41:23AM +1000, Haroon Anwar wrote:
> Hi Matt,
> 
> Thanks for you reply. Just got a question, what if I
> mount filesystems with the "noatime" options so that
> when it accesses a file it does not update the atime
> on the inode? What will amanda do then? Work on file
> size? 
> Is there any way, I can force amanda to work on file
> size rather than on the basis of "atime"  for the
> incremental backups.

You mean, if I edit a file but the size doesn't change
it need not be backed up in an incremental?  Hardly.
Size is the determining factor, nor should it be.

atime is not the basis for determing the need for a
backup either.  The "a" in atime stands for "access",
i.e. when were the data read.  Looking at the data
in a file should not cause it to be a candidate for
incremental backup.

Your system may vary, but on Solaris the noatime
mount option is not absolute.  I.e. under some
conditions atime is updated.  Basically if atime
needs updating when ctime or mtime are also being
updated the system will update atime even with
the option turned on.

What I think Matt was suggesting is that some process
on your system "might" be forcing the files atime
to be updated.  One example of a user level command
that does this is touch(1).  When a command like
touch is used to force a time stamp change, the
file's ctime is automatically changed as well.  A
ctime change will stimulate and incremental backup.


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