Networker

Re: [Networker] Windows 2000 not resetting the archive bit!!

2003-01-21 11:27:47
Subject: Re: [Networker] Windows 2000 not resetting the archive bit!!
From: "VERHAEGHE Koen (BMB)" <Koen.VERHAEGHE AT PROXIMUS DOT NET>
To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
Date: Tue, 21 Jan 2003 17:17:08 +0100
You might want to take a look at the Change Journal feature. We still
have some issues with that but we think that the reason there is that
our filesystems are clustered.
Other that that, great feature.

Cheers
Koen

-----Original Message-----
From: Robert Maiello [mailto:robert.maiello AT MEDEC DOT COM] 
Sent: Tuesday, January 21, 2003 3:52 PM
To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
Subject: [Networker] Windows 2000 not resetting the archive bit!!


We've been getting giant incrementals on a Windows 2000 6.1.2 client;
server in Solaris 8, 6.1.2.

Apparently some large permission changes were being made. The archive
bit of
the files were changed by this.   The weekday incremental backups then
back
up these files but does not reset/clear the archive bit.  Each day then
the
same data gets backed up.   Only a full backup will clear these archive
bits.

I received the reply below from Legato...the infamous "working as
designed". I was wondering if anyone else backing up W2K is having this
problem and how you dealed with?  Did it always behave this way?

I must say, for the life me, I don't understand Legato's logic.  The
definition of an incremental backup is everthing that's changed since
the last incremental...not backup the files forever as their archive bit
is set (regardless of how it was set).

I'm concerned also, that if we ignore the arhive bit then we'll miss
files in
our backups?   Again, how is everyone handling this Networker "design".

---
During incremental backups Networker
does not turn the archive bit off, if it is already on.
This is normal behaviour as designed. Please see below. Therefore, we
should make sure that the archive bit was not turned on by somebody else
or another program, before the backup. If that is the case then it is
different from the expected behaviour.

You may have to consider to set the environment variable
to yes.

Here is the behaviour as designed:

Handling archive bits depends on the value of the environment variable:
NSR_AVOID_ARCHIVE:

1) NSR_AVOID_ARCHIVE=no *or* not present (default)
This is the new default behavior of scheduled backups on NT by using the
Archive file attribute as another factor in determining if a file needs
to be backed up incrementally in addition to the Last Written, Creation
time of a file. The Archive file attribute is turned off based on the
criteria listed below after a schedule backup.

   A) full scheduled backups
       archive-bit(Attribute file attribute) turned off if on

   B) Last Written time *or* Creation time >= last scheduled backup time
       file is backed up, archive-bit turned off if on

   C) Last Written time *and* Creation time < last scheduled backup time
        a) archive-bit is on
            file is backed up, archive-bit will not get turned off until
            the file is "captured" by a later future scheduled backup
            (typically case A above, but possibly case B)
        b) archive-bit is off
            file is not backed up

2) NSR_AVOID_ARCHIVE=yes (any value other than case insensitive "no")
    This is the older behavior of scheduled backup without using the
    archive bit, except for older filesystem which used archive-bit as
in (1).

     A) full scheduled backups

     B) Last Written time *or* Creation time >= last scheduled backup
time
          file is backed up

     C) Last Written time *and* Creation time < last scheduled backup
time
          file is not backed up

By specifying NSR_AVOID_ARCHIVE environment variable, one can turn off
the new default archive-bit backup behavior. After changing this
environment variable, the NetWorker/NT client must be rebooted to get
the proper effect.


Robert Maiello
Thomson Healthcare

--
Note: To sign off this list, send a "signoff networker" command via
email to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can also
view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=


**** DISCLAIMER ****

"This e-mail and any attachment thereto may contain information which is 
confidential and/or protected by intellectual property rights and are intended 
for the sole use of the recipient(s) named above. 
Any use of the information contained herein (including, but not limited to, 
total or partial reproduction, communication or distribution in any form) by 
other persons than the designated recipient(s) is prohibited. 
If you have received this e-mail in error, please notify the sender either by 
telephone or by e-mail and delete the material from any computer".

Thank you for your cooperation.

For further information about Proximus mobile phone services please see our 
website at http://www.proximus.be or refer to any Proximus agent.

--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=