Does the job eventually fail?  What is the status code?  What kind of errors are you seeing in the bpbrm log of the media server, the bpcd log of both the media server and the client?  Also, what happens when you use:

bpclntcmd -pn
bpclntcmd -hn
bpclntcmd -ip

on the client, media server and master?

Regards,

Benjamin Schmaus

NetBackup does not care about IP address. As long as hostname can be resolved to IP address and backwards (IP to hostname) at TCP/IP level, everything should work.
Use bpclntcmd to test comms in ALL directions as suggested above.
U can also use 'bptestbpcd -client <client_name>' to test connection to client as well as connect back.
If you have media servers, do the same test to clients.
Create bpcd log on client to troubleshoot comms problems.

Try to use to use /etc/hosts as much as possible disable DNS. If you DNS master server does do name lookup and try to learn about the machines.  you have to be sure that reserve name lookup everything is working fine.

Connecting/Connected message usually means connection to client, not to tthe media server.

You mentioned flush dns on master and media, but you did not mention anything about flushing DNS on client.

When it comes to restore, the NetBakcup Client will need to reverse-lookup the IP address of the replica master server and then verify it against the SERVER entries in registry/bp.conf.

In other words, if you only flush DNS on the master and media, not on the client, then the client will get some odd name from the reverse-lookup of the replica master's IP address, and it will then reject the restore connection from the replica master, thinking that "oh, this is not my master server, because the name I found from DNS does not match the master name in my configuration"

Well, if flushing DNS on the client does not resolve the issue, then I think as a last resort you might want to update the hosts file on all three - master and media and client.

After you update all 3 system's hosts files, you know the name resolution should definitely work (well, test pings by name, to be sure) and then see if the restore works.

This will at least confirm if the restore failure/hang is because of the changed IP address or something else (different firewall settings in replica DR network, or something like that)

Good luck,

Abe

Thanks for the tips folks, I'll give these a try the next time I'm able to failover to the test DR server (hopefully by tommorow).

Abesama, I thought I flushed DNS on the client machine as well, but I'm not positive I did there. I was trying to restore the client files to the media server, so I was thinking that might take the client out of the loop. I'll test that out as well.