MS SQL and other XBSA Backups fail with status code 239 reported after applying the NetBackup 184.108.40.206 maintenance release.
NetBackup for Microsoft SQL Server backups fail with status code 239 (the specified client does not exist in the specified policy) reported after applying the NetBackup 220.127.116.11 maintenance release.
Other XBSA based backups such as DB2 and Oracle RMAN have also been reported to fail for the same reason.
Sample log snippets:
INF - BACKUP STARTED USING
Microsoft SQL Server 2008 (SP1) - 10.0.2531.0 (X64)
Mar 29 2009 10:11:52
Copyright (c) 1988-2008 Microsoft Corporation
Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7600: ) (VM)
Batch = SQL_BCK_LOGS.bch, Op# = 1
INF - Using backup image
INF - backup log "BA_SupplyChain" to VIRTUAL_DEVICE='VNBU0-6976-2800-1392709178'
with stats = 10, checksum, stop_on_error, blocksize = 65536, maxtransfersize =
4194304, buffercount = 2
INF - Number of stripes: 1, Number of buffers per stripe 2.
INF - Created VDI object for SQL Server instance <name>. Connection timeout
is <300> seconds.
Backup started Tue Feb 18 18:39:38 2014
2/18/2014 15:39:47.524 [Debug] NB 51216 nbpem 116 PID:6768 TID:5360 File ID:116
[jobid=-1 job_group_id=-1 client=sydssql05 type=2 server=*NULL*
task=ID:000000000570B848 CTX:000000000570B848 policy=P-P21-BE-SQL-LOGS] 4
[ExtReqTask::taskCompleted] (ID:000000000570B848 CTX:000000000570B848) writing
remote with <Backup by <media server> client <client name> using policy
P-P21-BE-SQL-LOGS:the specified client does not exist in the specified
The client hostname in the policy doesn't precisely match the same client's hostname in the batch file - for example, the case (upper vs. lower) may be different, or the hostname may be unqualified in one while fully-qualified in the other.
The formal resolution for this issue (Etrack 3439810) is included in the following release:
- NetBackup 7.6 GA
NetBackup 7.6 is currently available.
If upgrading to NetBackup 7.6 is unfeasible, please perform the following workaround:
For SQL policies:
Change the client hostname in the policy to exactly match the SQLHOST in the batch file OR add a BROWSECLIENT keyword to the batchfile (unless it is a clustered SQL server, in which case the BROWSECLIENT keyword is already listed in the batch file) and enter the hostname here exactly as it is configured in the Policy.
Confirm client names are identical in terms of case and length (Fully Qualified Domain Name [FQDN] or short (unqualified) hostname) in the policy and in the Backup, Archive, and Restore (BAR) GUI and MS SQL Client on the SQL servers:
1. Check the client name in the NetBackup policy for case and as to whether it is using a short hostname or FQDN.
2. On the MS SQL server > Start > Veritas > Netbackup > Backup Archive and Restore > File > Netbackup Client Properties > General tab, confirm the client name is IDENTICAL to the one listed in the policy .
3. On the MS SQL server > Start > Veritas > Netbackup > Netbackup Agents > Netbackup MS SQL Client > File > Manage scripts > Select appropriate script file > click OPEN File button > File will open - confirm the client hostname is identical.
For Oracle RMAN and DB2 policies:
The work around is very similar to that of SQL policies. The client name in the NetBackup policy can be changed or the name in any .bch file or RMAN SEND NB_ORA_CLIENT name and the DB2 client name in $home/bp.conf.
This issue affects the NetBackup 18.104.22.168 version ONLY.
Was this content helpful?
Rating submitted. Please provide additional feedback (optional):