cancel
Showing results for 
Search instead for 
Did you mean: 

Oracle client Template didnot show in Master server

tien86
Level 4
Partner

Master Server: Windows Server 2008 R2, NBU 7.6.0.1, License Trial Full.

Linux Client: Centos 6.5 Oracle 11g2

 

Following this guide: 

https://www-secure.symantec.com/connect/articles/netbackup-75-oracle-11g-linux#comment-10494841

 

I can backup file policy from this client.

 

Then I install a database, create several templates. In client: Backup, Archive and Restore GUI. Administer Templates, I can see my templates.

But when I create Oracle Policy, Select Template in drop box, the templates that I create didn't show.

 

I think connection between client and master is OK, but I dont get why the master server cannot retrieve oracle information from client.

 

Is it something problem or I am missing some configuration steps?

1 ACCEPTED SOLUTION

Accepted Solutions

Marianne
Level 6
Partner    VIP    Accredited Certified

Comms for DB agent is a bit different to file system backups.

For DB agent backups, comms is initiated from the client.

Double-check forward and reverse name lookup in all directions and test port connectivity (port 1556 - PBX) 

Create bpcd log folder under /usr/openv/netbackup/logs on the client and bprd log folder on the master under ...\netbackup\logs. Restart NBU Request Service.

On Master server:

bpclntcmd -hn <client-name>
bpclntcmd -ip <client-IP>

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

On Client:

bpclntcmd -hn <master-name>
bpclntcmd -ip <master-IP>
bpclntcmd -self
bpclntcmd -pn

The important one here is 'bpclntcmd -pn' as this will initiate a connection request from the client.
The master will try to resolve client IP to hostname that appears in client policy.
Is this the same name as can be seen in 'bpclntcmd -self' output? 
Same name as in Oracle policy?
The connection attempt from the client will be logged in bprd on the master.

When checking output of above, ensure hostnames resolve exactly the same everywhere.
Bear in mind that NBU is case sensitive.
CLIENT1 != client1 != client1.fqdn

If you need further assistance, please show us contents of above commands and upload log files. 
Copy them to .txt files before uploading (e.g. bpcd.txt)

 

View solution in original post

4 REPLIES 4

Marianne
Level 6
Partner    VIP    Accredited Certified

Comms for DB agent is a bit different to file system backups.

For DB agent backups, comms is initiated from the client.

Double-check forward and reverse name lookup in all directions and test port connectivity (port 1556 - PBX) 

Create bpcd log folder under /usr/openv/netbackup/logs on the client and bprd log folder on the master under ...\netbackup\logs. Restart NBU Request Service.

On Master server:

bpclntcmd -hn <client-name>
bpclntcmd -ip <client-IP>

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

On Client:

bpclntcmd -hn <master-name>
bpclntcmd -ip <master-IP>
bpclntcmd -self
bpclntcmd -pn

The important one here is 'bpclntcmd -pn' as this will initiate a connection request from the client.
The master will try to resolve client IP to hostname that appears in client policy.
Is this the same name as can be seen in 'bpclntcmd -self' output? 
Same name as in Oracle policy?
The connection attempt from the client will be logged in bprd on the master.

When checking output of above, ensure hostnames resolve exactly the same everywhere.
Bear in mind that NBU is case sensitive.
CLIENT1 != client1 != client1.fqdn

If you need further assistance, please show us contents of above commands and upload log files. 
Copy them to .txt files before uploading (e.g. bpcd.txt)

 

tien86
Level 4
Partner

Thank for your suggestion I would save as for furthur trouble shooting...

I type all the command, and looks all works.

I just resolve by close Netbackup Administration console and re-open. I am backing up and will update if any problem with my case

 

 

====

Master


C:\Program Files\Veritas\NetBackup\bin>bpclntcmd -hn host1.lab.tora
host host1.lab.tora: host1.lab.tora at 10.10.10.21
aliases:     host1.lab.tora     10.10.10.21


C:\Program Files\Veritas\NetBackup\bin>bpclntcmd -ip 10.10.10.21
host 10.10.10.21: 10.10.10.21 at 10.10.10.21
aliases:     10.10.10.21

C:\Program Files\Veritas\NetBackup\bin\admincmd>bptestbpcd -client host1.lab.tora -debug -verbose
15:35:34.498 [4128.5888] <2> bptestbpcd: VERBOSE = 0
15:35:34.514 [4128.5888] <2> vnet_pbxConnect: pbxConnectEx Succeeded
15:35:34.514 [4128.5888] <2> logconnections: BPCD CONNECT FROM 10.10.10.160.57076 TO 10.10.10.21.1556 fd = 388
15:35:34.514 [4128.5888] <2> vnet_pbxConnect: pbxConnectEx Succeeded
15:35:34.654 [4128.5888] <8> do_pbx_service: [vnet_connect.c:2152] via PBX VNETD CONNECT FROM 10.10.10.160.57077 TO 10.10.10.21.1556 fd = 408
15:35:34.654 [4128.5888] <8> vnet_vnetd_connect_forward_socket_begin: [vnet_vnetd.c:443] VN_REQUEST_CONNECT_FORWARD_SOCKET 10 0xa
15:35:34.654 [4128.5888] <8> vnet_vnetd_connect_forward_socket_begin: [vnet_vnetd.c:460] ipc_string /usr/openv/var/tmp/vnet-43724411147551479436
15:35:35.262 [4128.5888] <2> bpcr_get_version_rqst: bpcd version: 07600000
1 1 1
10.10.10.160:57076 -> 10.10.10.21:1556
10.10.10.160:57077 -> 10.10.10.21:1556
15:35:35.465 [4128.5888] <2> bpcr_get_peername_rqst: Server peername length = 18
15:35:35.668 [4128.5888] <2> bpcr_get_hostname_rqst: Server hostname length = 16
15:35:35.871 [4128.5888] <2> bpcr_get_clientname_rqst: Server clientname length = 16
15:35:36.074 [4128.5888] <2> bpcr_get_version_rqst: bpcd version: 07600000
15:35:36.276 [4128.5888] <2> bpcr_get_platform_rqst: Server platform length = 17
15:35:36.479 [4128.5888] <2> bpcr_get_version_rqst: bpcd version: 07600000
15:35:36.682 [4128.5888] <2> bpcr_patch_version_rqst: theRest == > <
15:35:36.682 [4128.5888] <2> bpcr_get_version_rqst: bpcd version: 07600000
15:35:36.932 [4128.5888] <2> bpcr_patch_version_rqst: theRest == > <
15:35:36.932 [4128.5888] <2> bpcr_get_version_rqst: bpcd version: 07600000
PEER_NAME = master1.lab.tora
HOST_NAME = host1.lab.tora
CLIENT_NAME = host1.lab.tora
VERSION = 0x07600000
PLATFORM = linuxR_x86_2.6.18
PATCH_VERSION = 7.6.0.1
SERVER_PATCH_VERSION = -1.-1.-1.-1
MASTER_SERVER = master1.lab.tora
EMM_SERVER = master1.lab.tora
NB_MACHINE_TYPE = CLIENT
15:35:37.134 [4128.5888] <2> vnet_pbxConnect: pbxConnectEx Succeeded
15:35:37.150 [4128.5888] <8> do_pbx_service: [vnet_connect.c:2152] via PBX VNETD CONNECT FROM 10.10.10.160.57078 TO 10.10.10.21.1556 fd = 416
15:35:37.150 [4128.5888] <8> vnet_vnetd_connect_forward_socket_begin: [vnet_vnetd.c:443] VN_REQUEST_CONNECT_FORWARD_SOCKET 10 0xa
15:35:37.181 [4128.5888] <8> vnet_vnetd_connect_forward_socket_begin: [vnet_vnetd.c:460] ipc_string /usr/openv/var/tmp/vnet-43727411147554004386
10.10.10.160:57078 -> 10.10.10.21:1556
<2>bptestbpcd: EXIT status = 0
15:35:37.384 [4128.5888] <2> bptestbpcd: EXIT status = 0

==========================
Client

[root@host1 bin]# ./bpclntcmd -hn master1.lab.tora
host master1.lab.tora: master1.lab.tora at 10.10.10.160
aliases:     master1.lab.tora     10.10.10.160
[root@host1 bin]# 
[root@host1 bin]# ./bpclntcmd -ip 10.10.10.160
host 10.10.10.160: master1.lab.tora at 10.10.10.160
aliases:     master1.lab.tora     10.10.10.160
[root@host1 bin]# 
[root@host1 bin]# 
[root@host1 bin]# ./bpclntcmd -self
yp_get_default_domain failed: (12) Local domain name not set
NIS does not seem to be running: (1) Request arguments bad
gethostname() returned: host1.lab.tora
host host1.lab.tora: host1.lab.tora at 10.10.10.21
aliases:     host1.lab.tora     10.10.10.21
getfqdn(host1.lab.tora) returned: host1.lab.tora
[root@host1 bin]# 
[root@host1 bin]# 
[root@host1 bin]# 
[root@host1 bin]# ./bpclntcmd -pn
expecting response from server master1.lab.tora

10.10.10.21 host1.lab.tora 10.10.10.21 55319

 

 

Marianne
Level 6
Partner    VIP    Accredited Certified

Note how reverse lookup of client IP did not return a hostname:

C:\Program Files\Veritas\NetBackup\bin>bpclntcmd -ip 10.10.10.21
host 10.10.10.21: 10.10.10.21 at 10.10.10.21
aliases:     10.10.10.21

tien86
Level 4
Partner

I haven't setup reverse lookup zone.

I just setup reverse lookup zone for this AD. 

So as you said "The master will try to resolve client IP to hostname that appears in client policy".

 

This is maybe the cause of the problem. I will monitor whether problem happen then.