Testing the master server and clients
If the NetBackup, installation, and configuration troubleshooting procedures do not reveal the problem, perform the following procedure. Skip those steps that you have already performed.
The procedure assumes that the software was successfully installed, but not necessarily configured correctly. If NetBackup never worked properly, you probably have configuration problems. In particular, look for device configuration problems.
You may also want to perform each backup and restore twice. On UNIX, perform them first as a root user and then as a nonroot user. On Windows, perform them first as a user that is a member of the Administrators group. Then perform them as a user that is not a member of the Administrator group. In all cases, ensure that you have read and write permissions on the test files.
The explanations in these procedures assume that you are familiar with the backup processes and restore processes. For further information, see the NetBackup Logging Reference Guide.
Several steps in this procedure mention the All Log Entries report. To access more information on this report and others, refer to the following:
See the NetBackup Administrator's Guide, Volume I.
Table: Steps for testing the master server and clients
Step | Action | Description |
---|
Step 1 | Enable debug logs. | Enable the appropriate debug logs on the master server.
For information on logging, see the NetBackup Logging Reference Guide.
If you do not know which logs apply, enable them all until you solve the problem. Delete the debug log directories when you have resolved the problem. |
Step 2 | Configure a test policy. | Configure a test policy to use a basic disk storage unit. Or, configure a test policy and set the backup window to be open while you test. Name the master server as the client and a storage unit that is on the master server (preferably a nonrobotic drive). Also, configure a volume in the NetBackup volume pool and insert the volume in the drive. If you don't label the volume by using the bplabel command, NetBackup automatically assigns a previously unused media ID. |
Step 3 | Verify the daemons and services. | To verify that the NetBackup daemons or services are running on the master server, do the following: To check the daemons on a UNIX system, enter the following command: /usr/openv/netbackup/bin/bpps -x To check the services on a Windows system, use the NetBackup Activity Monitor or the Services application of the Windows Control Panel.
|
Step 4 | Backup and restore a policy. | Start a manual backup of a policy by using the manual backup option in the NetBackup administration interface. Then, restore the backup.
These actions verify the following: NetBackup server software is functional, which includes all daemons or services, programs, and databases. NetBackup can mount the media and use the drive you configured.
|
Step 5 | Check for failure. | If a failure occurs, check the job's Detailed Status in the Activity Monitor. You can also try the NetBackup All Log Entries report. For the failures that relate to drives or media, verify that the drive is in an UP state and that the hardware functions.
To isolate the problem further, use the debug logs.
For an overview of the sequence of processing, see the information on backup processes and restore processes in the NetBackup Logging Reference Guide.
|
Step 6 | Consult information besides the debug logs. | If the debug logs do not reveal the problem, check the following: Systems Logs on UNIX systems Event Viewer and System logs on Windows systems Media Manager debug logs on the media server that performed the backup, restore, or duplication The bpdm and bptm debug logs on the media server that performed the backup, restore, or duplication
See the vendor manuals for information on hardware failures. |
Step 7 | Verify robotic drives. | If you use a robot and the configuration is an initial configuration, verify that the robotic drive is configured correctly.
In particular, verify the following: On a UNIX NetBackup server, you can verify only the Media and Device Management part of the configuration. To verify, use the tpreq command to request a media mount. Verify that the mount completes and check the drive on which the media was mounted. Repeat the process until the media is mounted and unmounted on each drive from the host where the problem occurred. If this works, the problem is probably with the policy or the storage unit configuration. When you are done, tpunmount the media. |
Step 8 | Include a robot in the test policy. | If you previously configured a nonrobotic drive and your system includes a robot, change your test policy now to specify a robot. Add a volume to the robot. The volume must be in the NetBackup volume pool on the EMM database host for the robot.
Return to step 3 and repeat this procedure for the robot. This procedure verifies that NetBackup can find the volume, mount it, and use the robotic drive.
|
Step 9 | Use the robotic test utilities. | If you have difficulties with the robot, try the test utilities.
Do not use the Robotic Test Utilities when backups or restores are active. These utilities prevent the corresponding robotic processes from performing robotic actions, such as loading and unloading media. The result is that it can cause media mount timeouts and prevent other robotic operations like robotic inventory and inject or eject from working. |
Step 10 | Enhance the test policy. | Add a user schedule to your test policy (the backup window must be open while you test). Use a storage unit and media that was verified in previous steps.
|
Step 11 | Backup and restore a file. | Start a user backup and restore of a file by using the client-user interface on the master server. Monitor the status and the progress log for the operation. If successful, this operation verifies that the client software is functional on the master server.
If a failure occurs, check the NetBackup All Log Entries report. To isolate the problem further, check the appropriate debug logs from the following list.
On a UNIX system, the debug logs are in the /usr/openv/netbackup/logs/ directory. On a Windows computer, the debug logs are in the install_path\NetBackup\logs\ directory.
Debug log directories exist for the following processes: bparchive (UNIX only) bpbackup (UNIX only) bpbkar bpcd bplist bprd bprestore nbwin (Windows only) bpinetd (Windows only)
Explanations about which logs apply to specific client types are available. For information on logging, see the NetBackup Logging Reference Guide.
|
Step 12 | Reconfigure the test policy. | Reconfigure your test policy to name a client that is located elsewhere in the network. Use a storage unit and media that has been verified in previous steps. If necessary, install the NetBackup client software.
|
Step 13 | Create debug log directories. | Create debug log directories for the following processes: bprd on the server bpcd on the client bpbkar on the client nbwin on the client (Windows only) bpbackup on the client (except Windows clients) bpinetd (Windows only) tar On the media server: bpbrm, bpdm, and bptm
Explanations about which logs apply to specific client types are available. For information on logging, see the NetBackup Logging Reference Guide.
|
Step 14 | Verify communication between the client and the master server. | Perform a user backup and then a restore from the client that is specified in step 8. These actions verify communications between the client and the master server, and NetBackup software on the client.
If an error occurs, check the job's Detailed Status in the Activity Monitor. check the All Log Entries report and the debug logs that you created in the previous step. A likely cause for errors is a communications problem between the server and the client. |
Step 15 | Test other clients or storage units. | When the test policy operates satisfactorily, repeat specific steps as necessary to verify other clients and storage units. |
Step 16 | Test the remaining policies and schedules. | When all clients and storage units are functional, test the remaining policies and schedules that use storage units on the master server. If a scheduled backup fails, check the All Log Entries report for errors. Then follow the recommended actions as is part of the error status code.
|