NetBackup™ Troubleshooting Guide
- Introduction
- Troubleshooting procedures
- About troubleshooting procedures
- Troubleshooting NetBackup problems
- Troubleshooting installation problems
- Troubleshooting configuration problems
- Device configuration problem resolution
- Testing the master server and clients
- Testing the media server and clients
- Resolving network communication problems with UNIX clients
- Resolving network communication problems with Windows clients
- Troubleshooting vnetd proxy connections
- vnetd proxy connection requirements
- Where to begin to troubleshoot vnetd proxy connections
- Verify that the vnetd process and proxies are active
- Verify that the host connections are proxied
- Test the vnetd proxy connections
- Examine the log files of the connecting and accepting processes
- Viewing the vnetd proxy log files
- Troubleshooting security certificate revocation
- Troubleshooting cloud provider's revoked SSL certificate issues
- Troubleshooting cloud provider's CRL download issues
- How a host's CRL affects certificate revocation troubleshooting
- NetBackup job fails because of revoked certificate or unavailability of CRLs
- NetBackup job fails because of apparent network error
- NetBackup job fails because of unavailable resource
- Master server security certificate is revoked
- Determining a NetBackup host's certificate state
- Troubleshooting issues with external CA-signed certificate revocation
- About troubleshooting networks and host names
- Verifying host name and service entries in NetBackup
- Example of host name and service entries on UNIX master server and client
- Example of host name and service entries on UNIX master server and media server
- Example of host name and service entries on UNIX PC clients
- Example of host name and service entries on UNIX server that connects to multiple networks
- About the bpclntcmd utility
- Using the Host Properties window to access configuration settings
- Resolving full disk problems
- Frozen media troubleshooting considerations
- Troubleshooting problems with the NetBackup web services
- Troubleshooting problems with the NetBackup web server certificate
- Resolving PBX problems
- Troubleshooting problems with validation of the remote host
- Troubleshooting Auto Image Replication
- Troubleshooting network interface card performance
- About SERVER entries in the bp.conf file
- About unavailable storage unit problems
- Resolving a NetBackup Administration operations failure on Windows
- Resolving garbled text displayed in NetBackup Administration Console on a UNIX computer
- Troubleshooting error messages in the NetBackup Administration Console
- Extra disk space required for logs and temporary files for the NetBackup Administration Console
- Unable to logon to the NetBackup Administration Console after external CA configuration
- Troubleshooting file-based external certificate issues
- Troubleshooting Windows certificate store issues
- Troubleshooting backup failures
- Troubleshooting backup failure issues with NAT clients or NAT servers
- Troubleshooting issues with the NetBackup Messaging Broker (or nbmqbroker) service
- Issues with email notifications for Windows systems
- Issues with KMS configuration
- Issues with initiating the NetBackup CA migration because of large key size
- Issues with the non-privileged user (service user) account
- Issues with group name format in the auth.conf file
- Troubleshooting the VxUpdate add package process
- Issues with FIPS mode
- Issues with malware scanning
- Issues with NetBackup jobs that are enabled for data-in-transit encryption
- Issues with Unstructured Data Instant Access
- Using NetBackup utilities
- About NetBackup troubleshooting utilities
- About the analysis utilities for NetBackup debug logs
- About the Logging Assistant
- About network troubleshooting utilities
- About the NetBackup support utility (nbsu)
- About the NetBackup consistency check utility (NBCC)
- About the NetBackup consistency check repair (NBCCR) utility
- About the nbcplogs utility
- About the robotic test utilities
- About the NetBackup Smart Diagnosis (nbsmartdiag) utility
- About log collection by job ID
- Disaster recovery
- About disaster recovery
- About disaster recovery requirements
- Disaster recovery packages
- About disaster recovery settings
- Recommended backup practices
- About disk recovery procedures for UNIX and Linux
- About clustered NetBackup server recovery for UNIX and Linux
- About disk recovery procedures for Windows
- About clustered NetBackup server recovery for Windows
- Generating a certificate on a clustered master server after disaster recovery installation
- About restoring disaster recovery package
- About the DR_PKG_MARKER_FILE environment variable
- Restoring disaster recovery package on Windows
- Restoring disaster recovery package on UNIX
- About recovering the NetBackup catalog
- About NetBackup catalog recovery on Windows computers
- About NetBackup catalog recovery from disk devices
- About NetBackup catalog recovery and symbolic links
- About NetBackup catalog recovery
- NetBackup disaster recovery email example
- About recovering the entire NetBackup catalog
- Establishing a connection with NAT media server before catalog recovery
- About recovering the NetBackup catalog image files
- About recovering the NetBackup relational database
- Recovering the NetBackup catalog when NetBackup Access Control is configured
- Recovering the NetBackup catalog from a nonprimary copy of a catalog backup
- Recovering the NetBackup catalog without the disaster recovery file
- Recovering a NetBackup user-directed online catalog backup from the command line
- Restoring files from a NetBackup online catalog backup
- Unfreezing the NetBackup online catalog recovery media
- Steps to carry out when you see exit status 5988 during catalog recovery
- Index
About troubleshooting networks and host names
In a configuration with multiple networks and clients with more than one host name, NetBackup administrators must configure the policy entries carefully. They must consider the network configuration (physical, host names and aliases, name services such as NIS or DNS, routing tables, and so on). If administrators want to direct backup and restore data across specific network paths, they especially need to consider these things.
For a backup, NetBackup connects to the host name as configured in the policy. The operating system's network code resolves this name and sends the connection across the network path that the system routing tables define. The bp.conf file is not a factor when making this decision.
For restores from the client, the client connects to the master server. For example, on a UNIX computer, the master server is the first one named in the /usr/openv/netbackup/bp.conf file. On a Windows computer, the master server is specified on the drop-down of the Specify NetBackup Machines and Policy Type dialog box. To open this dialog, start the NetBackup Backup, Archive, and Restore interface and click on the File menu. The client's network code that maps the server name to an IP address determines the network path to the server.
Upon receipt of the connection, the target host determines the peer host name of the connecting host. If the target host is the master server, it also determines the client's configured name from the peer host name.
The peer name is derived from the IP address of the connection. This means that the address must translate into a host name (using the getnameinfo() network routine). This name is visible in the bpcd or bprd debug log when a connection is made as in the line:
bpcd: Connection from host peername ipaddress ...
bprd: Connection from host peername ipaddress ...
On a client, the peer host name for the connecting server must match a server or a media server entry in the local NetBackup configuration: Either as a string match or by comparison with the getaddrinfo() information for each server entry.
On the master server, the comparison is more complex.
The client's configured name is then derived from the peer name by querying the bpdbm process on UNIX/Linux hosts, or the NetBackup Database Manager service on Windows hosts.
The bpdbm process compares the peer name to a list of client names that are generated from the following:
All clients for which a backup was run
All clients in all policies
The comparison is first a string comparison. The comparison is verified by comparing the peer name to the list of client names.
If none of the comparisons succeed, a more brute force method is used, which compares all names and aliases that are found using getaddrinfo() for each client name in the list.
The configured name is the first comparison that succeeds.
If the comparison fails, in most cases bprd replaces the requesting client (as follows) with the peer name because the host names in the request are not under administrative control like the network and NetBackup configurations.
An example of a failed comparison:
The client has a new network interface and has changed the first server entry to take advantage of the new network. The name services on the master server resolve the new source IP of the client to a peer name that is not a network alias for any client in any policies.
These comparisons are recorded in the bpdbm debug log if VERBOSE is set. You can determine a client's configured name by using the bpclntcmd command on the client. For example:
# /usr/openv/netbackup/bin/bpclntcmd -pn (UNIX)
# install_path\NetBackup\bin\bpclntcmd -pn (Windows)
expecting response from server wind.abc.me.com danr.abc.me.com danr 194.133.172.3 4823
Where the first output line identifies the server to which the request is directed. The second output line is the server's response in the following order:
Peer name of the connection to the server
Configured name of the client
IP address of the connection to the server
Source IP address of the connection to the server
When the client connects to the server, it sends the following three names to the server:
Browse clientRequesting clientDestination client
The browse client name is used to identify the client files to list or restore from. The user on the client can modify this name to restore files from another client. For example, on a Windows client, the user can change the client name by using the Backup, Archive, and Restore interface. (See the NetBackup online Help for instructions). For this change to work, however, the administrator must also have made a corresponding change on the server.
See the NetBackup Administrator's Guide, Volume I.
The requesting client is the value from either CLIENT_NAME or the gethostname() function on the client.
The destination client name is a factor only if an administrator pushes a restore to a client from a server. For a user restore, the destination client and the requesting client are the same. For an administrator restore, the administrator can specify a different name for the destination client.
By the time these names appear in the bprd debug log, the requesting client name has been translated into the client's configured name.
The name that is used to connect back to the client to complete the restore is either the client's peer name or its configured name. The type of restore request (for example, from root on a server, from a client, to a different client, and so on) influences this action.
When you modify client names in NetBackup policies to accommodate specific network paths, the administrator needs to consider:
The client name as configured on the client. For example, on UNIX the client name is CLIENT_NAME in the client's bp.conf file. On a Windows client, it is on the General tab of the NetBackup Client Properties dialog box. To open this dialog box, select from the File menu in the Backup, Archive, and Restore interface.
The client as currently named in the policy configuration.
The client backup and archive images that already exist as recorded in the images directory on the master server. On a UNIX server, the images directory is /usr/openv/netbackup/db/images. On a Windows NetBackup server, the images directory is install_path\NetBackup\db\images.
Any of these client names can require manual modification by the administrator if the following is true: a client has multiple network connections to the server and list or restore requests from the client fail because of a connection-related problem.
The traceroute (UNIX) and tracert (Windows) programs can often provide valuable information about the configuration of the network.
The master server may be unable to reply to client requests, if the Domain Name Services (DNS) are used and the following is true: The name that the client obtains through its gethostname() library is unknown to the DNS on the master server. The client and the server configurations can determine if this situation exists. The gethostname() function on the client may return an unqualified host name that the DNS on the master server cannot resolve.
Although you can reconfigure name services, including the hosts file, this solution is not always desirable. For this reason, NetBackup provides a special file on the master server. This file is as follows:
/usr/openv/netbackup/db/altnames/host.xlate (UNIX)
install_path\NetBackup\db\altnames\host.xlate (Windows)
You can create and edit this file to force the desired translation of NetBackup client host names.
Each line in the host.xlate file has 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 peername client_as_known_by_server
The following describes the preceding variables:
key is a numeric value used by NetBackup to specify the cases where the translation is to be done. Currently this value must always be 0, which indicates a configured name translation.
peername is the value to translate. This is the value to which getnameinfo() on the master server resolved the source IP address from which the client connected.
client_as_known_by_server is the name to substitute for peername when the client responds to requests. This name must be the name that is configured in the NetBackup configuration on the master server, typically as a client in a policy. It should also be known to the name services used by master server, and must be known to the network services of the media server that performs the backup.
This following is an example:
0 danr danr.eng.aaa.com
When the master server receives a request for a configured client name (numeric key 0), the name always replaces the peer name.