ncflbc Logs for Exchange GRT backup on client is highly verbose after upgrade to Netbackup 7.5

[Ching-Yoong]

Hi,

Nearly 4 weeks after upgrading from Netbackup 7.1.0.1 to Netbackup 7.5, the C:\ of the exchange server where we installed the Netbackup agent was filled up last night.

I have noticed that "<install path>\NetBackup\logs\ncflbc\" folders taken up 10GB for 15days of logs where prior to upgrade, log file size is <100KB, but after upgrade the are multiple log files of 51MB per day. I have check that DebugLevel = 1 & DiagnosticLevel = 6 in nblog.conf are the same before and after the upgrade. So, I reckon that the ncflbc process should be highly verbose in Netbackup 7.5.

I have logged a support case 417022572 for this.

For those Netbackup 7.5 users that enable Exchange GRT backup, make sure that you monitor the diskspace usage of the Netbackup 7.5 client install path on your exchange server. Or you could reduce the debug level with command below when no troubleshooting are needed.
<Install path>\NetBackup\bin\vxlogcfg -a -p 51216 -o 351 -s DebugLevel=0 -s DiagnosticLevel=0

To check details

<Install path>\NetBackup\bin\vxlogcfg -l -p nb -o ncflbc
 

[Will_Restore]

verify these settings:

MaxLogFileSizeKB =

NumberOfLogFiles =

[MN_Pankaj]

That's quite a increase in verbose log size for ncflbc - I am checking on the cause of this. Did you provide one of those log files in the support case 417022572 ?

[Ching-Yoong]

Default.MaxLogFileSizeKB=51200
Default.NumberOfLogFiles=3

MaxLogFileSizeKB = 51200

NumberOfLogFiles = 3

We didn't modify any of this. It is default settings after installation/upgrade.

[Ching-Yoong]

I didn't rpovide the logs as not requested by the tech.

[Graham_P]

I have the same problem with Netbackup v7.1, and have Symantec case 416-546-144 open for this same problem.   I have found that when ‘Enable message-level cataloging when duplicating Exchange images that use Granular Restore Technology’ is enabled on the Master Server host properties (General Server tab), it continues to write log entries to show progress of the cataloging information, and it is this which seems to cause the ncflbc log to continually growing when duplication is in progress.  A little information can be found here;  http://www.symantec.com/business/support/index?page=content&pmv=print&impressions=&viewlocale=&id=HO...

This feature needs to be enabled to allow us to navigate granular item level in the B.A.R for images that only exist on tape (duplicated from disk to tape, but later expired on disk staging).  If you disable this feature, then it will no longer catalog and provide granular recovery for your images duplicated to tape, and presumably it should also stop the extra catalog logging in ncflbc.

I am waiting for a response from Symantec as to whether it is possible to keep the message-level cataloging info but disable the unnecessary extra calaloging info that gets logged in the ncflbc folder.  I'll reply back here if I get some positive feedback to share on this.

[Ching-Yoong]

New case 417-250-335 has been created after the tech proof that ncflbc log folder is not created when upgrade client to 7.5. I have provided the ncflbc logs pre & post upgrade to 7.5.

However, I just noticed that on the exchange client that we upgrade duirng webex session for case 417022572, the ncflbc log folder is created automatically after the Exchange GRT backup, we have 1.2GB logs file for the backup of 370GB exchange DB. This is even when the DebugLevel & DiagnosticLevel is et to 0 for ncflbc. So, I will now have to monitor the disk space on exchange client where the netbackup client is installed as ncflbc logs is huge and you can't turn it off.

We need the "msg-level cataloging when duplicating" else when we duplicate back from tape to disk, we can't restore individual email items if needed.

[MN_Pankaj]

Symantec Engineering (Rob Wi***) has found the problem in our code. This issue would be pursued via the Titan case that the customer has opened with Symantec Technical Support.

Thanks for bringing this issue to our attention.

[rawilde]

I will update a procedure to get a fix to this issue. Stay tuned.

[rawilde]

There is a fix available via support to fix the issue in NetBackup 7.5 with very verbose logging for Exchange GRT functionality.  You can reference the EEB fix for 2743111.

There is also a fairly easy work-around to resolve this.

You can modify the nblog.conf file with the following line under section 311

311.DebugLevel=0

[Graham_P]

Thanks for your feedback on this 'rawilde'.  I didn't edit the nblog.conf myself to add '311.DebugLevel=0' into the 311 section, but instead I used the following command as supplied by another Symantec support technician (Steve Kirscht);

\NetBackup\bin\vxlogcfg -a -p 51216 -o 311 -s DebugLevel=0

This command adds the following lines automatically into the 311 section in the nblog.conf

311.DebugLevel=0

311.AppMsgLogging=ON

This resolved the verbose logging from GRT backups on our Exchange server running Netbackup v7.1.

Thanks for your assistance.

[Ching-Yoong]

The C :\ of our exchange server fill up again last night. This is due to ncflbc folder with huge logs again after we patch the client with NBU 7.5.0.1. I check that the debuglevel for 311 is reseted back to 1 again after the patching.

I have to do this again

\NetBackup\bin\vxlogcfg -a -p 51216 -o 311 -s DebugLevel=0