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