BUG REPORT: NetBackup for Microsoft SQL Server, or NetBackup for Oracle database agents, or user initiated backups are failing with Status Code 41 after upgrading to NetBackup 6.5, 7.0, 7.5 or 22.214.171.124.
There is an incorrect DLL reference in the <install_path>\Veritas\NetBackup\nblog.conf file on the master.
The default entry for KeyName:Default.L10nLib in the nblog.conf file after the upgrade is:
NOTE: In most cases, <install_path> is C:\Program Files
After an upgrade from NetBackup 6.0, some database and user-initiated backups may fail. The nbjm process fails to write any messages to the progress and comm files on the client host, and the data flow never starts.
Child application jobs will show as active in the Activity Monitor and the job details will show that tapes will have been mounted and positioned, but there will be no further progress updates after the Begin Writing notification.
Normal file system backups that are initiated from the master to the same client are successful because they do not rely upon progress or comm file updates to initiate the data transfer.
The following log sequences show the nbjm process encountering a failure, which then leads to a dbclient timeout while awaiting for the missing comm/progress log updates.
The nbjm (OID 117) debug log shows a failure while attempting to perform the update to the comm file.
02/24/10 10:29:35.952 [Debug] NB 51216 nbjm 117 PID:6960 TID:6900 File ID:117 [No context] 1 [ProgLogComm::TranslateAndLog] (018378E8) xlatemsg (translated) failed with status=1, jobid=61317(../JMProgLogComm.cpp:547)
The dbclient log shows an error after CLIENT_READ_TIMEOUT expires without the expected update to the comm file.
10:40:41.435 [2040.4076] <2> logconnections: BPRD CONNECT FROM client.4627 TO master.13724
10:41:06.137 [2040.4076] <4> serverResponse: Not a candidate for alternate buffer method: shared memory is not in use.
11:41:15.706 [2040.4076] <16> readCommFile: ERR - timed out after 3600 seconds while reading from C:\Program Files\Veritas\NetBackup\Logs\user_ops\mssql\logs\0224110104037-2040-4272-000-000-prg
For machines which have been upgraded to NetBackup 6.5, confirm that <install_path>\VERITAS\NetBackup\bin\vxextwincat_1.dll exists on the master server. If it does, follow this procedure:
vxlogcfg -a -p NB -o Default -s L10nLib="<install path>\Veritas\NetBackup\bin\vxextwincat_3.dll"
After running the above command, be sure to verify the correct path was added to the nblog.conf file by opening it in a text editor (such as Notepad) and finding the vxextwincat substring. Compare it to the appropriate KeyName listed above for the version of NetBackup being run.
Note: It is not recommended to edit/modify the nblog.conf file using a text editor as this may corrupt the file. After viewing this using a text editor, make sure to not save the file before closing it.
Note: It is necessary to stop and restart nbjm (or all of NetBackup) on the master server to pickup the change.
Then, retry the failed backup - it should succeed.
ETA of Fix:
Symantec has acknowledged that the above mentioned issue (Etrack 1987535) is present in the current version(s) of the product(s) mentioned at the end of this article. Symantec is committed to product quality and satisfied customers. This issue was scheduled to be addressed in the following release:
- NetBackup 7.0 Release Update 1 (7.0.1)
There are currently no plans to fix this issue in a future NetBackup 6.5 Release Update. Please use the workaround listed above if this issue is encountered with any NetBackup 6.5.x release.
Please note that Symantec Corporation reserves the right to remove any fix from the targeted release if it does not pass quality assurance tests or introduces new risks to overall code stability. Symantec's plans are subject to change and any action taken by you based on the above information or your reliance upon the above information is made at your own risk.