I coud be wrong, but this looks to be the issue ...

01:19:09.000 [5600.3140] <2> hosts_equal: gethostbyname failed for BackupMASTER.masterdomain.com: The requested name is valid, but no data of the r (0)

Seems to be some name resolution issue  - gethostbyname is a OS system call, it appears to be failing in some way.

Martin

OK, so the systems have been added to each others host files, and still an issue. Thoughs on what else I could look at?

OK, has the log chaged ?

As a change has been made, have to recheck the log I'm afraid ...

Martin

Negative, I kinda forgot about the host file thing. I did that late last night. I'm a little burned out on this issue here.

OK, from the master run:

/usr/openv/netbackup/bin/support/nbdna - the output location of the logs is given when it finishes.

Might not tell us anything new, but until we run it we will not know.

Martin

The master is a windows 2003 server. how do I run that command?

... try ....\netbackup\bin\support directory.

Go from the command line, and thinking about is, run

nbdna -phase 2

If the command is not there download from here :

http://www.symantec.com/docs/TECH125454

M

Is the master in fact listed as a valid server in the NBU config on the client. Checking the log, it seems to successfully lookup the name, but it compares to a completely different name.

So on the client, what does the master server entry say in the BAR GUI?

/A

Opps, spot the mistake, run the nbdna from the client ...

Whatever the incoming IP address resolves to on the client (hostname), it's not in the clients Server list.

That is the issue.

OK ... do this ...

Check on the client what the first SERVER entry is listed (in the registry).

hkey_local_machine > software > veritas >netbackup > currentversion > config

If the correct name of the master server is listed, than the name resolution is not working.

If it is not the correct name of the master server, then change it so that it is.

M

along with marianne suggestion also check

if you are able to ping BackupMASTER.masterdomain.com from client

and also check by pining your Mater server IP from client and make sure that is resolving the name of your master server that you keep in  Registory.

if those are not happening, you may need to look in etc/hosts file and add the entry of the master name and IP in client hosts file.

Hope this helps.. 

Alright so I had to quit yesterday and go home, I was just seeing the same thing and was burned out and tired. BUT walked in this morning, went through the below steps:

Check on the client what the first SERVER entry is listed (in the registry).

hkey_local_machine > software > veritas >netbackup > currentversion > config

If the correct name of the master server is listed, than the name resolution is not working.

If it is not the correct name of the master server, then change it so that it is.

And it turned out I had completely missed that the log said the client was looking for BackupMASTER and  BackupMASTER.legacydomain.com. When it should have been looking for Backupmaster.masterdomain.com. Now when I looked at the registry entries it said:

Backupmaster

Backupmaster

No domains or anything. Went through the BAR entries and the only entry in there is the one for Backupmaster. I also did a search of the registry for Backupmaster.legacydomain.com and no such luck. So where is it pulling that from? I think if I fix that it should solve the issue. 

1. Check client's hosts file
2. Check DNS reverse lookup from client:
nslookup 'master-ip-address'.

You may want to update Client's hosts file as this is normally used first.

OK, so I found that other registry entry under 

HKLM\SOFTWARE\VERITAS\NetBackup\CurrentVersion\Config\Server

and fixed that by making sure it specified the correct server and domain.

I already manually input the the systems into each other's host files this morning. 

Nothing has pointed to why the client was EVER looking for MasterServer.LEGACYDOMAIN.com

It should never have been looking there in the first place as the Master Server never lived on the domain from what I'm told. I'm looking for a .dll, .cab or .ini file that may be incorrect. All settings in the registry are correct, so the registry has been ruled out. There are no references to legacydomain.com at all in the registry.

After running nslookup 'master-ip' it comes up correctly.

NBU uses OS system call called 'gethostbyaddr' for reverse lookup. 

So, you need to find out what your OS uses for this system call. Default is normally hosts file, then DNS.

See: http://www.symantec.com/docs/TECH27430

OK, I've already added them to the host file. I'm 95% sure it was not the issue in the first place as there were no incorrect entries in the hostfile. It has to be somewhere other than DNS or the host file.

On a side note, as I said before I had two systems I fixed before with this method. NOW one of them have crapped out again, I'm going to set it to run logs tonight. detials to follow.

Why not just add the resolved hostname that you see in bpcd log to client's SERVER entries?

Lets go basic

what are the output of

from client:

run: 

bpclntcmd -pn
bpclntcmd -hn  <master server hostname>

bpclntcmd -ip <master server ip>

bpclntcmd -self

from master server

bpclntcmd -hn  <client hostname>

bpclntcmd -ip  <client ip>

---------------------------------------------------------------------
netstat -an 

bptestbpcd -client <client name> -debug -verbose

----------------------------------

check client bp.conf
check client name with right interface

Hi,

Adding to Ah45, Please issue the below command.

bpclntcmd -clear_host_cache.

Hi Marianne,

Thanks again for correcting me. 

OK, so I made some changes to the host file's on the servers, I tried something different on each one for the back up system. On one it now recognizes the backup server as a valid server, BUT I've run into this

OK, first post says

Connection from host BackupMASTER.masterdomain.com

and your latest post says

Connection from host Masterserver.legacydomain.com

which is correct?  you need to sort this out with server admins.

The second is now correct since I edited the host file to direct it to the legacy domain.

gethostbyname failed for Masterserver.legacydomain.com

Please check your hosts file. There are no entry for Masterserver.legacydomain.com in hosts file.
Also check if Masterserver.legacydomain.com exists in server list(SERVER line in bp.conf).

@eagle470 - we are stitting at comment no 31 (this one will be 32) and we are no closer to a solution for an error code that should have been solved in no more that 2 - 3 posts....

I fully understand that you don't want to post actual host names and IP addresses but without seeing what you see, it's difficult to tell you why it is still not working.

My suggestion:

Please choose someone in this thread who you trust enough to send a Private Message with real info.

Please send the following:

1. Contents of Client's hosts file.
2. The 'Server' entries in Client's registry (use regedt32 (NOT regedit) for easy-to-copy list)

3. This section of bpcd log file:

For all o fyou who have helped me with this and finding where to look, thank you very much. A working backup system is the best christmas an admin could ever ask for! 

The solution was actually very simple. I simply added the Masterserver.legacydomain.com and it's IP address to the host file AND I added the Masterserver.legacydomain.com to the BAR and to the registry entries mentioned in the comments above. That enabled it to talk finally. Everything appears to be working and the one server that I tested it on intially was able to backup just fine last night. 

Today I made all the same changes to the other two systems and now they are connecting to the Master server with no issue! Thank you very much all!

So my hostname lookup hunch was correct ... super, at one point I was getting a bit worried ...

M

Yeah, I just didn't have it added in enough locations correctly, and being a new environment, I was unaware that they had three NIC's setup on three different domains on the Master Server. Just took a while to figure out what I was dealing with.