--On Thursday, August 11, 2005 10:41:23 +1000 Haroon Anwar <hilarious_nick AT 
yahoo.com DOT au> 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.

Amanda (or more accurately, dump or tar) doesn't care about
atime. I have atime updates disabled on my NFS servers to
improve performance (with the tradeoff of loss of information
on how recently files were accessed) and incremental backups
work as expected.
atime is the last time a file was read
mtime is the last time the data in a file was written (either originally
  or modified)
ctime is the last time the file's inode was modified 

Things that change mtime also change ctime, but not the other
way around, i.e. editing will update the mtime, which also causes
a change in the ctime.  Changing the ownership or permissions,
however, only updates the ctime and not the mtime.

dump uses ctime, tar can use ctime or mtime depending on the options
used, but I believe for --listed-incremental (the way Amanda calls it)
it uses ctime.

As someone else pointed out, you don't want to use file size as a
criteria, much can change and still have the same size.

Since you said your full backup was 18 GB and your incremental was
only 10GB, you must actually be doing incrementals (or it would have
been 18GB also), so something is modifying nearly half of your data.
   It could be a process that chowns some directories, or even that
you are archiving part of your data onto the same filesystem and
have one huge file that is always 'new' even though its components
are mostly the same data.  Another possibility is something like a
CVS tree that gets cleaned and checked out making the files appear
new.

Try looking at the indexes of what is on your incremental and see
what is there, and then figure out what makes it appear 'new'.

Frank

> 
> Your help in this regard will be higly appareciated.
> 
> Thanks
> 
> Regards
> 
> haroon
> 
> 
> 
> 
> --- Matt Hyclak <hyclak AT math.ohiou DOT edu> wrote:
> 
>> On Tue, Aug 09, 2005 at 12:33:26PM +1000, Haroon
>> Anwar enlightened us:
>> > I am having problem with incremental backups.
>> Every
>> > thing is working
>> > fine. I force full backup of all my servers on
>> > Saturday. From Sunday
>> > to Friday I am taking incremental backup.
>> > 
>> > It is working fine. But, what my understanding of
>> > incremental backup
>> > is, starting from level 0 backup, amanda will
>> backup
>> > only those files
>> > which change. It should backup only the difference
>> or
>> > the changes. But
>> > this does not seem to be happening. E.g, One of my
>> > server disk is 18G.
>> > On Saturday I backup 18G. But on Sunday, I expect
>> > amanda to backup
>> > only the difference. But, its backing up around
>> 10G
>> > still and I dont
>> > think that the data on the server disk change that
>> > much. All the other
>> > servers are behaving in the same manner.
>> > 
>> > Can someone help me how can I achieve only to
>> backup
>> > the new files or
>> > the files that change when the incremental backup
>> > kicks off.
>> > 
>> > I force incremental backups by putting no-full
>> line in
>> > global secation
>> > of the dumptype and inhereting global settings in
>> the
>> > other dumptypes.
>> > 
>> 
>> First, you're really fighting what amanda was
>> designed to do...you're trying
>> to make "her" do what you want instead of letting
>> her do her own thing.
>> 
>> That being said, I would look at the 10GB of files
>> and see what is causing
>> them to be backed up. There are several things that
>> could cause this, such
>> as some script that accesses the files (changing
>> their atime attribute,
>> causing them to be considered new), etc. I would
>> examine what processes are
>> running on your servers that might be modifying the
>> files in such a manner
>> to get at the root of the problem.
>> 
>> Matt
>> 
>> -- 
>> Matt Hyclak
>> Department of Mathematics 
>> Department of Social Work
>> Ohio University
>> (740) 593-1263
>> 
> 
> 
> 
>               
> ____________________________________________________ 
> Do you Yahoo!? 
> Yahoo! Photos: Now with unlimited storage 
> http://au.photos.yahoo.com



--
Frank Smith                                                fsmith AT hoovers 
DOT com
Sr. Systems Administrator                                 Voice: 512-374-4673
Hoover's Online                                             Fax: 512-374-4501