mtimeasm
          The mtimeasm is used to backup  files  using  the  file
          mtime for file selection instead of the file ctime.

Would this help?  Perhaps a .nsr file in that directory of "+mtimeasm: * .*"?

--Joe

George Sinclair wrote:

What concerns me is the *amount* of data. This is forcing almost a tape
every night, but prior to the implementation of the cron script that's
running these chmods, the affected file system was backing up maybe a
fraction of a tape, not  even a gig. In fact, it would sit on a tape for
maybe a week or more. Now, it's eating through several tapes a week all
because a few directories are being chmoded. Of course, I'm not gonna
just blindly skip the data and yes, I realize the importance of having
all the file attributes in place when you recover it -- very good point
-- BUT I think in some very specific cases that may depend on the data
in question versus the amount of tape usage. In this particular example,
there are VERY specific paths that are being chmoded, and these are not
system files scattered around wherein failure to properly recover the
correct attributes could cause problems (security or otherwise).
Instead, these are all buried down under the same user data area. If the
users don't care that the recovered attributes are not the same, and all
they care about is that the data files themselves are the same, then
they could always run chmod again after the data has been recovered just
as the script does. In fact, I've looked at the script, and it runs the
same chmod on the whole thing every night in exactly the same way every
time. If they agree to it, then it seems that using some type of
directive like mtimeasm (not sure if this works or not) would be a
relief. Of course, it's something they need to understand ahead of time
and be prepared for. Would not consider this without proper testing and
user acceptance, but again, this is not something that I've had problems
with before. This is the first time I've seen this kind of problem on
any tape usage level that I would consider looking into.

George

Davina Treiber wrote:

George Sinclair wrote:

Is there a way to tell NetWorker to only back up a file if its
modification time has changed and not its changetime? Or maybe, when the
modification time changes, the changetime changes, too? I guess what I'm
asking is if there's a way to NOT back up the files if only something
like permissions, group, user, etc. has changed and only back it up if
there's actually been a modification to the file itself and not merely
its meta data.

For example, if some joker runs something like 'chmod -R u+x' against a
directory, NetWorker will re-backup all those files since the changetime
has now been affected. As near as I can tell there's no way to directly
change the changetime, but doing anything like chmod, chown or chgrp
against a file will affect a new changetime, and NetWorker definitely
appears to notice.

We have a large directory where someone is running a script that uses
chown, chgrp and chmod against it every night, but the modification
times are not changing. Essentially causes as much data as a full to get
backed up during incrementals.

No there isn't a way to do this and I can't imagine anyone within Legato
thinking it would be a good idea to provide this feature, I certainly
think it would be pretty dumb. When you do a recovery you expect all the
attributes of the recovered files to be the same as they were on the
date selected for the recovered data. If the attributes of a file are
being modified then it has to be regarded as a change so it needs to be
backed up, no question about it in my opinion.

What is it that concerns you about this? Is it the extra time taken for
the backups, or the media used? I think if you will do the sums you will
find that the saving in media would barely justify the time taken for
you to post these questions to the list. It's probably not even worth
worrying about.

--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listserv.temple DOT edu or visit the list's Web site at
http://listserv.temple.edu/archives/networker.html where you can
also view and post messages to the list. Questions regarding this list
should be sent to stan AT temple DOT edu
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listserv.temple DOT edu or visit the list's Web site at
http://listserv.temple.edu/archives/networker.html where you can
also view and post messages to the list. Questions regarding this list
should be sent to stan AT temple DOT edu
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=

--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listserv.temple DOT edu or visit the list's Web site at
http://listserv.temple.edu/archives/networker.html where you can
also view and post messages to the list. Questions regarding this list
should be sent to stan AT temple DOT edu
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=