(25) cannot connect on socket when using SQL intelligent policy for a client

[traghav86]

Good Day

i am getting error with 1: (25) cannot connect on socket  when using SQL intelligent policy for a client.

the same client working with sql batch file .

client is running on 7.7.3

[Marianne]

Please show us output of bptestbpcd on the master:

bptestbpcd -client <client-name> -debug -verbose

[traghav86]

Hi Marianne

Local drive backup and SQL backup with batch file is running without any issues.

output as per your request

F:\Veritas\NetBackup\bin\admincmd>bptestbpcd -client nrtmhrdbs301 -debug -verbose
11:41:52.934 [8072.7268] <2> bptestbpcd: VERBOSE = 0
11:41:52.950 [8072.7268] <2> vnet_pbxConnect: pbxConnectEx Succeeded
11:41:52.950 [8072.7268] <2> logconnections: BPCD CONNECT FROM 10.0.65.27.52550 TO 10.0.65.201.1556 fd = 536
11:41:52.965 [8072.7268] <2> vnet_pbxConnect: pbxConnectEx Succeeded
11:41:53.121 [8072.7268] <8> do_pbx_service: [vnet_connect.c:2302] via PBX VNETD CONNECT FROM 10.0.65.27.52551 TO 10.0.65.201.1556 fd = 552
11:41:53.121 [8072.7268] <8> vnet_vnetd_connect_forward_socket_begin: [vnet_vnetd.c:455] VN_REQUEST_CONNECT_FORWARD_SOCKET 10 0xa
11:41:53.137 [8072.7268] <8> vnet_vnetd_connect_forward_socket_begin: [vnet_vnetd.c:480] ipc_string 61676
11:41:53.262 [8072.7268] <2> bpcr_get_version_rqst: bpcd version: 07730000
1 1 1
10.0.65.27:52550 -> 10.0.65.201:1556
10.0.65.27:52551 -> 10.0.65.201:1556
11:41:53.278 [8072.7268] <2> bpcr_get_peername_rqst: Server peername length = 12
11:41:53.293 [8072.7268] <2> bpcr_get_hostname_rqst: Server hostname length = 12
11:41:53.309 [8072.7268] <2> bpcr_get_clientname_rqst: Server clientname length = 12
11:41:53.325 [8072.7268] <2> bpcr_get_version_rqst: bpcd version: 07730000
11:41:53.340 [8072.7268] <2> bpcr_get_platform_rqst: Server platform length = 7
11:41:53.356 [8072.7268] <2> bpcr_get_version_rqst: bpcd version: 07730000
11:41:53.371 [8072.7268] <2> bpcr_patch_version_rqst: theRest == > <
11:41:53.371 [8072.7268] <2> bpcr_get_version_rqst: bpcd version: 07730000
11:41:53.387 [8072.7268] <2> bpcr_patch_version_rqst: theRest == > <
11:41:53.387 [8072.7268] <2> bpcr_get_version_rqst: bpcd version: 07730000
PEER_NAME = nrecnetbk211
HOST_NAME = nrtmhrdbs301
CLIENT_NAME = nrtmhrdbs301
VERSION = 0x07730000
PLATFORM = win_x64
PATCH_VERSION = 7.7.3.0
SERVER_PATCH_VERSION = 7.7.3.0
MASTER_SERVER = nrecnetbk211
EMM_SERVER = nrecnetbk211
NB_MACHINE_TYPE = CLIENT
11:41:53.465 [8072.7268] <2> vnet_pbxConnect: pbxConnectEx Succeeded
11:41:53.590 [8072.7268] <8> do_pbx_service: [vnet_connect.c:2302] via PBX VNETD CONNECT FROM 10.0.65.27.52552 TO 10.0.65.201.1556 fd = 564
11:41:53.590 [8072.7268] <8> vnet_vnetd_connect_forward_socket_begin: [vnet_vnetd.c:455] VN_REQUEST_CONNECT_FORWARD_SOCKET 10 0xa
11:41:53.606 [8072.7268] <8> vnet_vnetd_connect_forward_socket_begin: [vnet_vnetd.c:480] ipc_string 61678
10.0.65.27:52552 -> 10.0.65.201:1556
<2>bptestbpcd: EXIT status = 0
11:41:53.731 [8072.7268] <2> bptestbpcd: EXIT status = 0

[Michael_G_Ander]

What does bpclntcmd -self  and bpclntcmd -pn on the SQL server show ?

Have seen this kind of error, if there are mismatch between the client name in different places. For example if the client name is lower case on the Netbackup server and the client name send the name in upper case.

My first ports of call with database backup problems, is always the dbclient & bphdb logs.

Have done a more detailed description of my way of troubleshooting db backups, here:

https://vox.veritas.com/t5/NetBackup/General-database-backup-error-troubleshooting/m-p/675381

[Marianne]

I totally get what you are saying - script based SQL backups work fine. 
It is just Intelligent Policy backups failing.

I am trying to find the process flow diagram/info for SQL IP but have not been able to locate it in the Admin Guides or online. 

Are you saying that config has been fine?
Discovery of Instances?
Configuring credentials?
Registering SQL Instances?

If all of this worked fine, then I find it totally strange that comms will only fail at the time of backup.

There are no different/special ports being used for SQL IP.

[traghav86]

thats correct

Are you saying that config has been fine?--Yes
Discovery of Instances?--yes
Configuring credentials?--yes
Registering SQL Instances?--yes

[Marianne]

Any chance that this is clustered SQL instance? 
Clustering is not (yet?) supported with SQL IP.

All I can suggest at this point is to get a 'second pair of eyes' to double-check the config with you.
I often find that a small step that gets overlooked can cause major headaches.
The 2nd pair of eyes may as well be a Veritas Support Engineer. 

[traghav86 · Accepted solution]

i dont think this is clustered becuase clusetered sql instance will have different name than host .

but dicover instances picked up instance same as host.. will investigate with veritas further

[traghav86 · Accepted solution]

Found the problem ..its a cluster resource hosting on different server which is not activated to netbackup.

Thanks Marianne.

[Marianne]

At least be fair and mark solution for the post that pointed you in the right direction.