01-15-2016 03:52 AM
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
Solved! Go to Solution.
02-04-2016 03:12 AM
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 :)
01-15-2016 04:29 AM
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
01-15-2016 05:06 AM
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.?
01-15-2016 05:50 AM
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.
01-15-2016 06:54 AM
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!
01-15-2016 07:23 AM
01-18-2016 09:05 AM
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
01-18-2016 11:45 AM
See page 15 of:
NetBackup 7.7 Logging Reference Guide
http://www.veritas.com/docs/000004638
...re how to control logging size and quantity.
01-19-2016 01:47 AM
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
01-19-2016 02:56 AM
Did you not open the link that I posted, and download the manual?
01-19-2016 06:40 AM
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.
01-19-2016 08:15 AM
Page 15 onwards doesn't mention the GUI. Why are you looking at the GUI?
01-25-2016 11:39 PM
Anything useful in bpbkar log as yet?
02-04-2016 03:12 AM
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 :)