06-09-2015 11:38 AM
Hi
This is my first post in this forum also I am new to Netbackup admin role.
I need your help in troubleshooting netbackup client server 6.5 on Red Hat Enterprise Linux Server release 5.6 (Tikanga).
We have NBU master server 7.1.0.4 on AIX 6.5 but this client have only NBU 6.5 in it and also it seems we cannot upgrade the NBU client version.
I am having problem in connecting with this client, can you please let me know how to start the services on NBU 6.5. generally I use "netbackup start" and "netbackup stop" to bounce the services but not sure how to do it in NBU 6.5.
Can some one please help in this.
Solved! Go to Solution.
06-09-2015 10:07 PM
If the telnet localhost is not working the the problem is in the client.
manual start the bpcd and vnetd:
bpcd -standalone
vnetd - standalone
and retry the telnet localhost.
If this test works then your problem should be the xinetd.
also check if selinux is enabled. netbackup does not work with selinux enabled out of the box.
if it is enabled change it to permissive or disabled.
06-09-2015 12:12 PM
Check if you can connect to the client from the client at the netbackup ports (telnet localhost 13782 and telnet localhost 13824). If you get an error, then the problem is on the client.
check the firewall (service iptables status) or xinetd (The 6.5 client in unix/linux is not always running. it uses xinetd to start the bpcd and vnetd. so first check if xinetd is running.)
Then check if you can connect to the netbackup server from the client and vice versa ( from client :telnet master_server_name 13782 and 137824 / from server: telnet client_host_name 13782 and 13724 ). always use hostnames and not IPs . Netbackup always use hostnames .
If the telnet is not working, then the problem is at your network or firewall level.
Last but not least check your DNS.
06-09-2015 01:00 PM
06-09-2015 01:58 PM
Thanks Stefan and Marianne for your reply, I did a check on "telnet localhost " with both the ports from the client itself but they did not worked. Firewall is disabled and confirmed xinetd is running.
also I am not able to connect to the client from master and master to client.
the netstat -a does not shows me these two ports even.
I just only have nbclient in /usr/openv/netbackup/bin/goodies
06-09-2015 02:14 PM
06-09-2015 02:20 PM
yes they are present, I do see them in that location.
vnetd 13724/udp # Veritas Network Utility
bpcd 13782/udp # VERITAS NetBackup
06-09-2015 10:07 PM
If the telnet localhost is not working the the problem is in the client.
manual start the bpcd and vnetd:
bpcd -standalone
vnetd - standalone
and retry the telnet localhost.
If this test works then your problem should be the xinetd.
also check if selinux is enabled. netbackup does not work with selinux enabled out of the box.
if it is enabled change it to permissive or disabled.
06-09-2015 10:52 PM
06-10-2015 08:57 AM
as suggested I started the BPCD as standalone after that I am able to do the telnet local host and the bptestbpcd from master worked fine but not able to start the VNETD as I don't find them.
when triggered the backup it is not able to connect with the client got the below error.
06/10/2015 08:33:41 - started process bpbrm (pid=16384074)
06/10/2015 08:33:41 - connecting
06/10/2015 08:43:43 - Error bpbrm (pid=16384074) cannot connect to xxx.xx.xx, status = 25
06/10/2015 08:53:49 - Error bpbrm (pid=16384074) timed out trying to connect to xxx.xx.xx
06/10/2015 08:53:49 - Info bpbkar (pid=0) done. status: 54: timed out connecting to client
06/10/2015 08:53:49 - end writing
also the selinux is disabled and per Marianne's suggestion I restarted the xinetd and did a netstat -a it showed the bpcd(it just shows when the bpcd is at standalone mode) also I am not able to ping any other server from the client except the master server.
netstat -a | grep 137
tcp 0 0 *:13782 *:* LISTEN
netstat -a | grep bpcd
unix 2 [ ACC ] STREAM LISTENING 22328071 /usr/openv/var/vnetd/bpcd.uds
06-10-2015 11:16 AM
06-11-2015 11:58 AM
Stefane and Marianne, thanks we got this backup fixed after brought down an bad etherner port.which had an wrong subnet mask on it.