Problems with backup, cannot connect on socket(25)
Master + Media servers: Netbackup 7.0.1, Windows Server 2003 R2
Clients: Netbackup 7.0.1, and 6.5.3, Windows Server 2008 (non-R2)
Getting consistent failures on 3 clients lately with error 25 on the child job, cannot connect on socket(25)
Happens with Full and Cumulative Incremental backups.
Have tried the following:
Rerun the jobs during the day (normally run at night) - Still fails
Created a brand new policy (not copying the old one) - Also fails
Telnet to BPCD port - Successful response from all servers to the clients
Adding the required network interface - Still fails
Changing the timeout connections - Still fails
Pinging/NSlookup/bptestbpcd from the master/media servers - Everything appears to be fine
Running bbps while the backups are starting I can see vnetd and bpcd start on the clients, but still it always fails with cannot connect on socket(25)
Any suggestions on things to check? I will post logs below.
So I ran one of the backups with the BPCD log on, and found the following (which wasn't in the bptestbpcd results one):
<16> bpcd main: get_vnetd_forward_socket failed: 21
Searching I found the following article:
http://www.symantec.com/business/support/index?page=content&id=TECH156471&key=15143&actp=LIST
Which advised the following:
Host Properties > Master server > server > Client Attributes > client > Connect Options
BPCD connect back = Random port
Ports = Non-reserved ports
Daemon connection port = Daemon port only
Tested that, it worked.
To test additionally I changed the setup to the following:
BPCD connect back = Default
Ports = Default
Daemon connection port = Daemon port only
Which also worked.
As soon as I switch Daemon connection port back to default we go back to the job failing.
So going by that article I'll need to identify the non-NetBackup process that is randomly connecting, as leaving the setting as Daemon port only is not a desired setup for us.
Looking further however I can't find anything connecting on the ports being requested in the vnetd log, so again I'm left with a puzzle of why this is failing on the default setting, especially considering 2 of the 3 affected clients were backing up without issue until last week, and no changes were applied to them in the time frame.
Thank you both for the log commands, helped point me in the right direction, and find a work around until I get a solution in place.