Scott,
You make a valid point. Using modification time as the SOLE reason to back
up a file is inadequate, which is why I enable TIR. I believe that TIR
would fix all of the issues that you list with modification time. I
haven't heard the problem that you're stating about TIR and modified date
stamp. Has anyone else heard this?
The purpose of my post was really aimed at what I feel is the stupidity of
the archive bit. Yes, it changes anytime you do anything in your list.
BUT, it's also changed many times when you do nothing but access the
file. I say this because I see the files that get backed up in an archive
bit-based backup. Things like executables that haven't been touched since
they were installed -- weird stuff like that.
Then there's the whole "two backup applications" problem. I agree that you
should not install two of them, but there is one installed already --
NTBACKUP. And nothing prevents joe user, or fledgling MCSE fred admin,
from using NTBACKUP to back up a portion of the box. It's kind of like
some of the other "landmines" that Windows has, as I wrote about in my
recent column:
http://storagemagazine.techtarget.com/strgFeature/0,291266,sid35_gci843161,00.html
(I wish I had put the archive bit thing in there. I forgot about that one.)
If you're AWARE and trained about these landmines, then they're harmless.
The problem is most people would have no clue that running an NTBACKUP of
the home directory would result in that directory not being backed up by
NetBackup.
At 10:00 PM 8/18/2002 -0500, scott.kendall AT abbott DOT com wrote:
>Not sure what happened here, but I just got this reply to a post from several
>months ago???
>
>The timestamps in an MS file system are a little different than UNIX and also
>behave a little differently. The three timestamps are created, modified and
>last access (instead of changed, modified and last access). Here are some
>differences...
>
>1. rename a file, archive bit is set, modified timestamp does not change
>2. move a file, archive bit is set, modified timestamp does not change
>3. copy a file, archive bit is set, modified timestamp does not change
>4. change security on a file, archive bit is set, modified timestamp does not
>change
>
>I think not backing up a file on an incremental after it has been renamed or
>not backing up a new file when it is copied/moved to the server until the next
>full is ran is more of a problem than trying to understand the archive bit and
>trying to avoid doing things that will cause issues (like using two backup
>apps on the same server as you mention below).
>
>Using TIR w/ move detection should avoid some of these issues, but I know TIR
>adds to the catalog size and I remember someone posting something stating that
>TIR didn't work when backing up based on modified date timestamp.
|
