We have been trying to assist for almost 2 months now, but you are not giving us sufficient info to work with.
As per previous requests, we need bprd log on the master server and dbclient log on the destination client for the same date.
We need to see on the client (dbclient log) how the request is generated and sent to the master.
We need to see on the master (bprd log) how the request is received and interpreted.
Client names is crucial in NBU when you want to restore.
The client name used in Policy is the name that needs to be used to list or restore.
There might be slight differences in hostname (Upper vs lower case, FQDN, etc) when backup is started from the master and when backup is started from the client.
The logs will give us more insight into hostname usage and resolution.
A possible workaround is to create aliases in hosts file on the master for all possible names for the client.
Another possibility is to create host.xlate file on the master server.
Extract from NBU Admin Guide II:
In some requests to the master server, client software sends the name that it obtains
through its gethostname library function (on Windows) or the gethostname(2)
library function (on UNIX/Linux). If the name is unknown to the master server Domain
Name Service, the master server may not be able to reply to client requests.
This possible situation depends on how the client and the server are configured. If
gethostname on the client (on Windows) or gethostname(2) on the client (on
UNIX/Linux) returns the host names that DNS on the master server cannot resolve,
problems occur.
One possible solution is to reconfigure the client or the master server DNS hosts
file. Another option is to create a special file in the altnames directory on the master
server. The file forces the translation of NetBackup client host names.
On Windows:
install_path\NetBackup\db\altnames\host.xlate
On UNIX/Linux:
/usr/openv/netbackup/db/altnames/host.xlate
Each line in the host.xlate file contains three elements: a numeric key and two
host names. Each line is left-justified, and a space character separates each element
of the line:
key hostname_from_ client client_as_known_by_server
Where
■ key is a numeric value used by NetBackup to specify the cases where translation
is to be done. Currently this value must always be 0, which indicates a configured
name translation.
■ hostname_from_client is the value to translate. The client name must correspond
to the name that is obtained by running the client’s gethostname (on Windows)
or gethostname(2) (on UNIX/Linux). The value must be sent to the server in
the request.
■ client_as_known_by_server is the name to substitute for hostname_from_client
for request responses. The name must match the name in the NetBackup
configuration on the master server and must also be known to the master server’s
network services.
Consider the following example:
0 xxxx xxxx.eng.aaa.com
The line specifies that when the master server receives a request for a configured
client name (numeric key 0), the name xxxx.eng.aaa.com always replaces xxxx.
The substitution resolves the problem if the following conditions are true:
■ When gethostname (on Windows) or gethostname(2)(on UNIX/Linux) is run
on the client, it returns xxxx.
■ The master server’s network services gethostbyname library function (on
Windows) or gethostbyname(2) library function (on UNIX/Linux) did not
recognize the name xxxx.
■ The client was configured and named in the NetBackup configuration as
xxxx.eng.aaa.com. And, this name is also known to network services on the
master server.
Hope this helps.............
