George,

It seems to me that the solution to this lies not in NetWorker, but in
what this user script is doing. If they are blindly chmod-ing the same
files each time with the same perms, even if the files already have
those perms, then a smarter script would improve things greatly. All
they need to do is a suitable find command with an action that checks
the existing perms and only chmods the files that need it. Not a complex
script - it would take marginally longer to run, but I'm sure you can
explain the benefits to your l^Husers.

D.

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
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=