cancel
Showing results for 
Search instead for 
Did you mean: 

Full backups not clearing the archive bit after successful backup

Dan_Vargas
Level 4

My cumulative incremental backups are taking forever because... Imagine the following scenario

File last modified 14/12/15
Full backup 08/01/16

If I run a command to query the archive bit (dir /a:a /o-d) , I see that the file is flagged for archiving.

Hence the file is being backed up in cumulative incremental backups because of this.

The file's archive bit should obviously be cleared after the full backup.

Any ideas of why this may be happening?

Landscape:

For the client I have two policies, one (A) for the DFSR folders (each DFSR folder manually added to take advantage of multiplexing and multiple data streams) and another (B) policy for ALL_LOCAL_DRIVES.

According to the admin guide, I set up exclusions for this client so the DFSR folders are only copied on A.  B backs up  the rest of the SCC. This works just fine.

BRM is enabled for B but not for A. I've seen that back in 2011 having TIR enabled (which is force if you have BRM) used to force full backups on DFSR scenarios. Not sure if this still is the case, but all the technotes regarding that are gone, so maybe that issue is gone for good.

Master/Media server run on the same server, and NBU version is 7.6.0.4.

NBU client for the client is 7.6.0.1

1 ACCEPTED SOLUTION

Accepted Solutions

Dan_Vargas
Level 4

Sorry, I've been busy with some other stuff. This was happening only to some specific folders, and eventually I realised it was because they were DFSR Read Only folders, which makes them unmodifiable (event for the system user) so NBU was unable to clear the backup bit. Changed ti timestamp backups and all working now :)

View solution in original post

13 REPLIES 13

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

Please check Host Properties for Archive Bit setting for the client.
The default value for 'Wait time before clearing archive bit' is 300 (5 min).
Extract from the manual:
"The client waits 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."

Enable bpbkar log on the client to see if clearing of Archive Bit is mentioned/attempted.

Please note that various other non-NBU events on a server can also set archive bits.
A workaround is to de-select 'Incrementals based on Archive bit'.

You may want to upgrade the client to the same version as the master/media server as there have been various improvements/fixes in NBU 7.6.0.2 (and later) for DFSR backups:

http://www.veritas.com/docs/000020086 

http://www.veritas.com/docs/000019459

 

Dan_Vargas
Level 4

Thanks Marianne,

My client's 'Wait time before clearing archive bit'  is 300.

What level of logging should I enable? I'll try with a test policy backing up to drive a subset of files.

but the most important question... What's more efficient, user the archive bit, or the timestamps?

I'll upgrade the client today, out of office hours. I think you are a *nix , but do you know if a reboot is needed after upgrading.?

 

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

Level 1 log should be fine.

What is more efficient? 
The option that works best in your environment.... 

See what you can find in the bpbkar log.
If you see a valid reson for archive bit not being cleared or failed attempt, please try the timestamp option.

I have not seen requests for reboot during/after upgrade in recent years - I update NBU client and/or Windows Admin Console software on my laptop on a regular basis.

Dan_Vargas
Level 4

Great, thanks.

Couple of questions:

When I asked about efficiency, I meant in terms of performance. I don't know if using timestamps means that the client will have to query NBU's catalog to compare timestamps for every single file, what sounds kind of resource consuming.

I'll check the logs too. Can I enable this on a policy basis instead of at a master server level?

Thanks again!

 

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified
In all honesty, I have never tried to determine impact on performance. bpbkar log folder is created on the client and will log all backup streams running on the client.

Dan_Vargas
Level 4

Hi Marianne,

 

I upgraded the client but I was running low on tapes and couldn't launch full backups, so I'm using timestamp backups at the moment, which seems to be working just fine.

 

Slightly unrelated question, is there a way to limit, autocompress, or similar the log files? They grow quite fast, as this server is a filer.

 

Thanks

sdo
Moderator
Moderator
Partner    VIP    Certified

See page 15 of:

NetBackup 7.7 Logging Reference Guide
http://www.veritas.com/docs/000004638

...re how to control logging size and quantity.

Dan_Vargas
Level 4

Hi,

 

I'm running 7.6 and in the logging section for the master server properties I don't see anything related to log size control.

 

Regards

sdo
Moderator
Moderator
Partner    VIP    Certified

Did you not open the link that I posted, and download the manual?

Dan_Vargas
Level 4

Hi, I did, but as I tried to explain earlier, that manual is for 7.7, not 7.6, and I don't see any options to limit the log size apart from "Save logs up to X days" in the client properties under Host Properties.

sdo
Moderator
Moderator
Partner    VIP    Certified

Page 15 onwards doesn't mention the GUI.  Why are you looking at the GUI?

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

Anything useful in bpbkar log as yet?

Dan_Vargas
Level 4

Sorry, I've been busy with some other stuff. This was happening only to some specific folders, and eventually I realised it was because they were DFSR Read Only folders, which makes them unmodifiable (event for the system user) so NBU was unable to clear the backup bit. Changed ti timestamp backups and all working now :)