cancel
Showing results for 
Search instead for 
Did you mean: 

Getting "EXIT STATUS 26: client/server handshaking failed" on redirected restores from a client

zmlat
Level 4

Hi community...

Here is the environment:
NB 8.3 on linux master/media servers, and 7.7.3 and up on the clients. We recently upgraded most clients to 8.1.2...right before it went out of support :( , but since the upgrade, we've been having issues with client-directed backups and restores. I have an open case with Veritas on the backup issues, since they wouldn't provide support until we upgraded to 8.2 on the few clients with the issues, but for the restore issue I think I found the fix, but would like to know the "why" this is happening on 8.x clients. 

We've been running 8.2 on the NB servers for a while, with most clients at 7.7.3. In that scenario, users were able to do redirected restores from dev hosts that were not backed up but had NB 7.7.3 client installed solely for restore purposes. After upgrading the dev clients to 8.1.2, the users were no longer able to do these restores. They would get the handshake error. I issued the nbcertcmd commands on the client, and I have "No.Restrictions" in altnames. DNS forward/reverse is OK, and I can ping to/from client to all NB servers. Same restore initiated from master works.

I tried to check client properties but couldn't since the restore client is not in any policy. So I added it to a dummy policy, and voila....restore worked.

I really do not want to start adding hosts which we do not backup to inactive policies for the sole purposes of  client-initiated,  redirected restores.

Hopefully someone can shed some light. Else I'll have to upgrade NB to 8.2 (seems trivial but for all the red-tape here) and open a call with Veritas.

Thanks

1 REPLY 1

Hamza_H
Moderator
Moderator
   VIP   

Hello,

You may want to take a look at this technote : https://www.veritas.com/content/support/en_US/article.100051511

it is not the same issue you have,but take a look at the Option 2 in the workaround:

Option 2.  Add a policy (can be inactive) that contains all the hostnames of the host involved in the restore, both the requesting host, and source/browse host, and the destination/target host.  The hostnames for each host should include the short name, fully qualified domain name, and any backup/private network hostnames in case name service resolution changes in the future.  Especially the peername to which the primary server resolves the requesting source IP address.

 

By adding the client in a policy, it speeds up the name resolution..

Btw, you can check the props of a client even if it is not in a policy, by clicking in "configure client" under Host properties > Clients > the icon with the computer up in the console.

 

try to also, to add the client in client attributes on the master server to check if that helps too.