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.edu or visit the list's Web site at
http://listserv.temple.edu/archives/networker.html where you can
should be sent to stan < at > temple.edu
--
Note: To sign off this list, send a "signoff networker" command via email
to listserv < at > listserv.temple.edu or visit the list's Web site at
http://listserv.temple.edu/archives/networker.html where you can
should be sent to stan < at > temple.edu
--
Note: To sign off this list, send a "signoff networker" command via email
to listserv < at > listserv.temple.edu or visit the list's Web site at
http://listserv.temple.edu/archives/networker.html where you can
should be sent to stan < at > temple.edu
Note: To sign off this list, send a "signoff networker" command via email
to listserv < at > listserv.temple.edu or visit the list's Web site at
http://listserv.temple.edu/archives/networker.html where you can
should be sent to stan < at > temple.edu
