Client initiated backup or restore failures after upgrading the master server to 8.1

Problem

The NetBackup 8.1 release has a number of security enhancements, including the deployment of certificates, and certificate revocation lists (CRL), among other changes.  Due to those enhancements, backups or restores initiated by clients may fail after upgrading the master server, regardless of the version of NetBackup installed on the client and with no changes being made to the client.

Examples of the behavior seen are:

1.  Client initiated backups that fail, which may not appear in the activity monitor.
2.  Restores that fail in any of the following manner:
   • bprd log file showing status 135
   • Handshaking error, status 26
   • Restores that never appear in the activity monitor.

** Note that these are examples and not a fully inclusive list.

 

Error Message

A few examples of errors that may be seen are as follows:

bprd log errors that report “EXIT STATUS 135”:

06:36:04.347 [26756.26756] <16> bpcd_remote_ops_allowed: Unknown remote host <nbclient1> is not allowed to run commands
06:36:04.348 [26756.26756] <2> vnet_check_vxss_server_magic: [vnet_vxss_helper.c:664] VxSS magic=329199, remote_vxss=97
06:36:04.348 [26756.26756] <2> vnet_check_vxss_server_magic: [vnet_vxss_helper.c:721] Ignoring VxSS authentication 2 0x2
06:36:04.348 [26756.26756] <2> process_request: command C_READ_TEXT_FILE (97) received
06:36:04.348 [26756.26756] <16> process_request: request failed, error=135
06:36:04.348 [26756.26756] <16> process_request: EXIT STATUS 135
 
Handshaking failed for command line initiated restores:
bprestore -C nbclient1 -D nbclient2 -S nbmaster1. -L /tmp/restore.log -R /tmp/restore -f /tmp/filelist
EXIT STATUS 26: client/server handshaking failed
 
 

Solution

If the bprd log shows “ EXIT STATUS 135” and “ <client-name> is not allowed to run commands” the following options exist to resolve the problem:
 
For backup failures:  Consult the appropriate workload specific 8.1 Administration Guide for best practices in regard to backups. 
 
For restore failures: If the failures are related to the applications Sharepoint, Exchange or MSSQL, consult the appropriate 8.1 Administration Guide for best practices.

Restore assistance for other workloads includes the following:
 
1. Configuration of the Distributed Application Restore Mapping ( DARM) list may resolve this issue.
The DARM’s list is located in Host Properties --> Master Server --> Distributed Application Restore Mapping:



The “ Application host” is the virtual name or name the application is backed up as in the NetBackup databases.
The “ Component host” is the node name.There should be one entry for each node associated with the application cluster.
 
 
2.  If using the No.Restrictions file, which is not recommended, add the client to the Host Properties --> Master Server -->Client Attributes list:



Each client that requires the ability to restore must have an entry in Client Attributes.

Using No.Restrictions is not recommended as it will allow clients which have entries in "Client Attributes" unfettered access to restores of other client(s) data.
 
3.   If “ No.Restrictions” is NOT configured, which is recommended, the client needs to be configured to allow restores to specific clients, by the existence of a file for that client in the altnames directory:
Windows:  <install_path>\NetBackup\db\altnames\client_name
Unix:  /usr/openv/netbackup/db/altnames/client_name
 
*Note that the altnames directory will not exist by default and much be created by the administrator.

Where  client_name is the name of the client that is allowed to perform the redirected restore (the destination client for the data).  The file should contain the name of the of the source client .
 
For example, if nbclient2 needs to be able to restore data backed up from nbclient1, the file name would be nbclient2.  The contents of the file would be:

 
See the NetBackup Administration Guide, Volume 1 for additional information.