I played around with mtimeasm, and it's very slick, but my testing shows
one major drawback when running incrementals. While using this option
will cause the backups to ignore files whose meta data has changed, and
only capture files whose modification time has changed, it ALSO causes
the backups to ignore any files that have been added since the last
backup but have older modification times. Not using this option fixes
that. For example, I created the following path:
/home/dir/bob
and I created a .nsr file under /home/dir as:
<< /home/dir/bob >>
+mtimeasm: * .?*
If I create some files under bob, and I run a backup, the backups
capture all the data which is what I would expect. Next, I change the
permissions on the files and re-run. This time nothing but the client's
index gets backed up. Again, due to the directive this is what I would
expect. HOWEVER, if I then 'cp -p' a file under bob and then re-run the
backups, it again backs up nothing. BUT, if I had instead removed the
.nsr file, or commented out the lines in it, then it would back up this
new file that has an older date than the last time the backups ran.
Interesting. So, it appears that while mtimeasm is useful, one needs to
be aware that it will prevent new files with time stamps older than the
last backup from getting backed up. At least this has been my experience
with incrementals. Any one else notice this behavior?
Another thing I notice is that if I change the permissions on a file,
and I run the backups with the directive in place, the affected files
don't get backed up. All fine, but if I then remove the directive and
re-run, again the files don't get backed up. Only if I change the
permissions again and re-run without the directive do they get captured.
It seems like removing the directive and re-running won't capture what
NetWorker skipped before.
George
Joe Moore wrote:
>
> There is a "mtimeasm" that is available to set in a directive, which is
> described in the uasm man page as:
> 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
> =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
--
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
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
