Veritas NetBackup™ Administrator's Guide, Volume II
- NetBackup licensing models and usage reporting
- How capacity licensing works
- Creating and viewing the licensing report
- Reviewing a capacity licensing report
- Reconciling the capacity licensing report results
- Reviewing a traditional licensing report
- Reviewing an NEVC licensing report
- Additional configuration
- About dynamic host name and IP addressing
- About busy file processing on UNIX clients
- About the Shared Storage Option
- DELETE About configuring the Shared Storage Option in NetBackup
- Viewing SSO summary reports
- About the vm.conf configuration file
- Holds Management
- Menu user interfaces on UNIX
- About the tpconfig device configuration utility
- About the NetBackup Disk Configuration Utility
- Reference topics
- Host name rules
- About reading backup images with nbtar or tar32.exe
- Factors that affect backup time
- NetBackup notify scripts
- Media and device management best practices
- About TapeAlert
- About tape drive cleaning
- How NetBackup reserves drives
- About SCSI persistent reserve
- About the SPC-2 SCSI reserve process
- About checking for data loss
- About checking for tape and driver configuration errors
- How NetBackup selects media
- About selecting media in robots
- About selecting media in standalone drives
- About Tape I/O commands on UNIX
Special considerations for Domain Name Service (DNS)
In some requests to the master server, client software sends the name that it obtains through its gethostname library function (on Windows) or the gethostname(2) library function (on UNIX). If the name is unknown to the master server Domain Name Service, the master server may not be able to reply to client requests.
This possible situation depends on how the client and the server are configured. If gethostname on the client (on Windows) or gethostname(2) on the client (on UNIX) returns the host names that DNS on the master server cannot resolve, problems occur.
One possible solution is to reconfigure the client or the master server DNS hosts file. Another option is to create a special file in the altnames directory on the master server. The file forces the translation of NetBackup client host names.
Each line in the host.xlate file contains 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 hostname_from_ client client_as_known_by_server
key is a numeric value used by NetBackup to specify the cases where translation is to be done. Currently this value must always be 0, which indicates a configured name translation.
hostname_from_client is the value to translate. The client name must correspond to the name that is obtained by running the client's gethostname (on Windows) or gethostname(2) (on UNIX). The value must be sent to the server in the request.
client_as_known_by_server is the name to substitute for hostname_from_client for request responses. The name must match the name in the NetBackup configuration on the master server and must also be known to the master server's network services.
Consider the following example:
0 xxxx xxxx.eng.aaa.com
The line specifies that when the master server receives a request for a configured client name (numeric key 0), the name xxxx.eng.aaa.com always replaces xxxx.
The substitution resolves the problem if the following conditions are true:
When gethostname (on Windows) or gethostname(2)(on UNIX) is run on the client, it returns xxxx.
The master server's network services gethostbyname library function (on Windows) or gethostbyname(2) library function (on UNIX) did not recognize the name xxxx.
The client was configured and named in the NetBackup configuration as xxxx.eng.aaa.com. And, this name is also known to network services on the master server.