cancel
Showing results for 
Search instead for 
Did you mean: 

Successful backup not clearing archive bit

GG_Stratos
Level 3
I am running Netbackup 6.0 MP4, and during the weekdays, I have a differential incremental backup running on a particluar server.  The files are being backed up successfully, but the archive bit isn't being cleared after the backup.  Has anyone experienced this?
 
Thanks.
13 REPLIES 13

Stumpr2
Level 6
It is a configuration variable. You can select whether or not to clear the archive bit upon successfull backups.
 
 
 

GG_Stratos
Level 3
Thanks.  Where exactly do you enable that option to clear the archive bit?  I can't see it in the policy settings...

sdo
Moderator
Moderator
Partner    VIP    Certified
I may be wrong, but IMHO there isn't a "clear archive bit" option as such - it's more a case of configuring a client (so see the client "Host Properties" in the GUI) to use either "incrementals based on timestamp" or "incrementals based on archive bit" for incremental backups.  What isn't clear to me is whether the archive bit is cleared if you use file "timestamp" instead of the "archive bit".
 
Also note that some disk/storage scavenging/archiving tools can also clear the archive bit which will confuse NetBackup immensely.
 
Also note this from the NBU Win v5.1 MP6 help files:
Note   NetBackup recommends that you do not combine differential incremental backups and cumulative incremental backups within the same Windows policy when the incremental backups are based on archive bit (default).

GG_Stratos
Level 3
it is set to do the incrementals based on archive bit... i haven't done any cumulative incrementals, so that's not an issue.  the archive bit is only being cleared after a full backup which runs on the weekend.  the files are definitely being backed up successfully during the week as i can view them through them the restore window... but for whatever reason, the archive bits aren't being cleared until a full backup runs.

sdo
Moderator
Moderator
Partner    VIP    Certified
I'm confused:
 
You say "i haven't done any cumulative incrementals".  Ok, but then you say "the files are definitely being backed up successfully during the week" - are you running full every day?
 
Also, you say "the archive bit is only being cleared after a full backup which runs on the weekend", and "but for whatever reason, the archive bits aren't being cleared until a full backup runs".  So I take it that the archive bit is being cleared - but the problem seems to be that successful backups aren't clearing the archive bit.
 
Sorry.  Can you re-explain?
 
 
Also, note that "cumulative incrementals" do *not* clear the archive bit - this is standard behaviour - this is so that cumulative incrementals are just that - i.e. they are "cumulative".  Only "differential incrementals" and "fulls" will clear the archive bit.
 
Also, note that the v5.1 MP6 GUI help files say this...

The Wait Time Before Clearing Archive Bit property specifies the number of seconds the client will wait before clearing the archive bits for a differential incremental backup. The minimum allowable value is 300 (default). The client waits this long for acknowledgment from the server that the backup was successful. If the server does not reply within this time period, the archive bits are not cleared.

This option applies only to differential-incremental backups. Cumulative-incremental backups do not clear the archive bit.

This property appears for Windows clients only.

GG_Stratos
Level 3
i'm running differential incrementals during the weekdays, not cumulative incrementals... i just pointed out that i wasn't using cumulative because a previous reply stated that you should not combine differential and cumulative.  so i just wanted to state that cumulatives weren't being used, and that only differentials are running during the weekdays.
 
so, to summarize the issue, the differential incrementals are not clearing the archive bit after a successful backup.   the archive bit is only being cleared after a full backup runs on the weekend.  i will try increasing the "wait time before clearing the archive bit" value to see if that helps.  thanks.

sdo
Moderator
Moderator
Partner    VIP    Certified
Ok, got it now, I was being dense.
 
Wondering what versions of NetBackup on the master, media and clients you have and their O/Ses and patch levels too?
 
Just checked the v6.0 MP5 Windows release notes:
...and can't see any mention of a fix for such a problem.  I'm guessing that this is either a new problem, or there is something specific to your configuration/set-up and/or mix of hardware/software etc.
 
Just curious, are archive bits not being cleared for every volume/disk/mount-point, or only certain paths?
Is the drive/path on a share or mapped drive?
NTFS version?  (try "$ fsutil fsinfo ntfsinfo C:", and/or the volumes affected?)

GG_Stratos
Level 3
master and media are 6.0 mp4... client is running ver. 5.1 of netbackup, and is a windows 2003 server with sp1 + updates.
 
so far, i've only noticed the problem on this one server... the volume that is affected is on san storage.  the ntfs version is 3.1.
 
i'll upgrade the client from 5.1 to 6.0 if increasing the timeout value of 300 doesn't work.  i changed that from 300 to 900 earlier.  thanks.

Martin_A
Level 3
I had noticed this occurring, diff incremnetals just grew all week until a full was run, but it only appeared to occur on Win2003 clients - I just switched to using Timestamps rather than archive bits and everything seems fine now.
 
Martin

sdo
Moderator
Moderator
Partner    VIP    Certified
This is curious indeed, as the account that the NetBackup client runs under (normally "System Authority") definitely has the access rights to clear the archive bit file attribute after full backups, but it isn't doing it during the differentials.
 
Do either of you have Symantec Support and feel like raising a proper case?

GG_Stratos
Level 3
Yes, I opened a case earlier... waiting on a callback now.  Thanks.

sdo
Moderator
Moderator
Partner    VIP    Certified
Good call.  There's a few of us who would like to know the result of this one.

Criss_R
Level 4
I am having the same issue. The way I have resolved this issue, was to create a new policy from scratch. I have also had some success with moving the client that was having the issue to another policy. Hope this helps. Smiley Happy