You are on page 1of 18

Error codes Troubleshooting

Status Code: 196 Status Code 58 Status Code 59

Status Code: 196


Client backup was not attempted because backup window closed
A Status Code 196 will occur when a backup job is in a queued state at the time the backup window for that job closes. If a job is active by the time the window closes, that active job will still run to completion. However, queued jobs will fail with status 196.

Status Code: 196 Client backup was not attempted because the backup window closed

Page 1 of 18

Status Code 196

Is Backup performance slower than expected on the streams that complete?

YES

General Backup Performance Issue Section 2

NO

Are tape drives up? YES Policy or Storage Unit Configuration Issue Section 1

NO

Enable/view the following logs: Unix: Syslog and Admin Messages Windows: Event Viewer System and application logs Also, view the Problems Report in the Administration Console.

Is the issue Resolved?

Drive Communication Issues Section 3

NO Enable/view the following logs: Unix: /usr/openv/netbackup/logs/bpsched Windows: <install_path>\NetBackup\ logs\bpsched

General Bpsched issues Section 4

Status Code: 196 Client backup was not attempted because the backup window closed

Page 2 of 18

Table of Contents
3 1 Managing Backup Policies and Storage Units.......................................................................................... 3

1.1 Policy Configuration..............................................................................................................3 1.1.1 Maximum Jobs per policy and client..............................................................................3 1.1.2 Additional Features/Options...........................................................................................4
2 Optimizing Backup Performance.............................................................................................................. 4

2.1 Identify Bottlenecks...............................................................................................................4 2.2 Multiplexing...........................................................................................................................5 2.2.1 Multiplexing - Planning..................................................................................................5 2.2.2 Multiplexing - Implementation.......................................................................................5 2.3 Eliminate Unnecessary Logging............................................................................................5
3 Verify hardware availability....................................................................................................................... 6 4 NetBackup Scheduler (bpsched) delays due to environmental problems.................................................6

4.1.1 Troubleshooting Status Code 58 ....................................................................................7


1 Server is not listed within the Clients Server list.....................................................................................15 2 Name Resolution.................................................................................................................................... 16

2.1 Multiple Nics.......................................................................................................................17 2.2 Fully Qualified Domain Names ....................................................................................................................................................17


3 Further Log Examination...................................................................................................................... 18

1 Managing Backup Policies and Storage Units


Effective policy management plays a major roll in completing backups within the time window. The first thing to consider is the backup window itself. Determine if the current backup window is reasonable for the volume of data being backed up and the available storage resources.

1.1 Policy Configuration


1.1.1 Maximum Jobs per policy and client
Policies have a setting for Limit jobs per policy. Ensure that this setting is not overly constrictive of jobs that could be running. If the maximum number of jobs is reached on the policy, additional jobs will queue. If this setting is too low, queued jobs may result in a status 196 despite the fact that they have the resources to run. Within Global Attributes under the Master Servers host properties, there is a setting for the Maximum jobs per client. This has an effect similar to that of Limit jobs per policy, but on the client level. If multiple data streams are being used, ensure that this setting is not constricting jobs that could be running. If the maximum number of jobs is reached on the client, additional jobs will queue.

Status Code: 196 Client backup was not attempted because the backup window closed

Page 3 of 18

1.1.2 Additional Features/Options


NetBackup 5.0 introduced a variety of features designed to use the backup window efficiently: Synthetic backups: Synthetic backups allow logical full and cumulative backups to take place without actually transferring data from the client. This can improve performance by providing the restore benefits of Full or Cumulative Incremental backups, without backing up redundant data during the backup window. Advanced Client backups: Advanced client backup methods such as Flashbackup involve snapshot backups. This can improve performance by backing up the raw data, which eliminates the overhead of querying every file on the file system level. Disk staging: Disk staging allows the staging of data to disk before ultimately moving to the final storage unit. This can reduce the required backup window by deferring the move from disk to tape until all client data is collected and the backup window closes.

2 Optimizing Backup Performance


Another method of avoiding the 196 error is to improve overall backup speed in order to complete all jobs within the designated window. This section offers some general guidelines for optimizing performance.

2.1 Identify Bottlenecks


Identifying where bottlenecks in the data flow exist is essential to improving performance. The following are some common methods of doing so: 1. Are there any common factors between poorly performing clients, such as OS platform, Network, or the Media Server being used? 2. Perform a backup to a disk storage unit for a poorly performing client. Is performance significantly improved? This can eliminate a tape storage unit and its data path as being part of the problem. 3. Determine whether the media server experiences performance issues during a local backup (backing up locally attached storage). This can eliminate the network and client as the primary bottlenecks. 4. Perform a backup to null on a poorly performing client. This allows the NetBackup client to process the data without actually sending it to the media server for backup. This can isolate the client itself as the bottleneck. See NetBackup technote 242918 for information on executing and analyzing this test. The results of tests such as these can assist in identifying areas to investigate further. Dependant on the results, some next steps may include: Checking for optimum Network duplex settings. Verifying the OEM recommended driver and firmware versions are installed for tape hardware. Adding additional hardware to satisfy the backup requirements (tape devices, SCSI / fiber equipment, etc.) Enabling the NetBackup multiplexing feature. Adjusting tape buffer sizes. Page 4 of 18

Status Code: 196 Client backup was not attempted because the backup window closed

2.2 Multiplexing
Multiplexing is a NetBackup feature allowing multiple streams of data to be written to a tape device concurrently. These streams may come from a variety of clients, even of dissimilar platforms. At times, a tape device may be capable of writing much faster than a single client can present data to the media server. In this scenario, multiplexing can significantly improve overall performance. Implementation of multiplexing should always be carefully considered. An environment which unnecessarily uses multiplexing may see no benefits or even diminished backup performance, and will always see a negative impact on restore performance. See the Multiplexing section of your NetBackup System Administrators Guide (reference Multiplexing in the index) for a full explanation on the multiplexing feature.

2.2.1 Multiplexing - Planning


Use the results from section 2.1 (Identifying Bottlenecks) to help determine if multiplexing is appropriate. For example, if it is found that there are no problems within the Media Server or the network, but the client processing is very slow, multiplexing may help significantly. Testing of both backup and restore performance should be done to determine the ideal multiplexing level for an environment. As an example, a value of three (at the storage unit level) is often found to be a good trade off between backup and restore performance.

2.2.2 Multiplexing - Implementation


Multiplexing is configured in three places: Within the Storage Unit, under Maximum multiplexing per drive. Within the Policy Attributes through the Allow Multiple Data Streams checkbox. Within the Policys Schedule in the Media Multiplexing setting.

As mentioned above, the following configuration options might also be relevant when configuring multiplexing: Limit jobs per policy (set in Policy Attributes) Maximum Jobs per Client (set in Global Attributes) Maximum Data Streams (set in Client Attributes)

See the VERITAS NetBackup System Administrators Guide for further information on multiplexing configuration.

2.3 Eliminate Unnecessary Logging


When not actively troubleshooting a NetBackup issue, debug logs should be disabled or kept at a very low verbose level. NetBackup debug logs can grow extremely large, and consume gigabytes of space under certain configurations. Verbose logging can also have a negative impact on performance. The bpsched and bpdbm logs particularly have a significant impact on resources, even when at a verbose level of 0. See the NetBackup System Administrators guide for information on creating and disabling logging, as well as manipulating the verbose level.

Status Code: 196 Client backup was not attempted because the backup window closed

Page 5 of 18

3 Verify hardware availability


Hardware problems (tape drive or robotic problems) can result in down tape drives. This means that NetBackup has fewer resources with which to complete backups. Use the NetBackup Device Monitor GUI to view the status of all the tape drives. If there are any down tape drives, examine the operating systems error logs to determine why the drives were downed. Running the Problems Report in the NetBackup Administration console may also assist in diagnosis. Additionally, it may be necessary to reconfigure, or verify the configuration of devices. See the Media Manager and Device Configuration Guides for more information on how to proceed with this.

4 NetBackup Scheduler (bpsched) delays due to environmental problems


The NetBackup scheduler process ("bpsched") is the process that is responsible for constantly scanning the NetBackup policy configuration and starting jobs at the time those jobs are due to run. Once a job is started, it is bpsched that monitors the availability of tape resources and activates new jobs as active jobs complete. In a large or complex NetBackup environment, it is not uncommon to occasionally encounter a scenario where the scheduler seems to be "stuck" or delayed. In extreme cases, this can result in status 196 failures for backups that would otherwise have no problems fitting in their backup window. There are a number of environmental problems, ranging from system resource shortages to network problems that can create this situation. See the related documents section of this technote for a detailed discussion of this topic.

Status Code: 196 Client backup was not attempted because the backup window closed

Page 6 of 18

4.1.1 Troubleshooting Status Code 58


STATUS CODE 58: Can't connect to client. Troubleshooting procedures for Status 58 errors. Exact Error Message status code 58: can't connect to client Details: Overview: A status 58 error results from either a TCP SYN request sent to a client from the NetBackup (NBU) server that was not acknowledged or the server was not resolvable so a TCP SYN request was not sent. The majority of the causes of this issue are due to the client not listening on the BPCD or VNETD ports, the master server unable to resolve the client by hostname, or the client can not resolve the NBU server by its IP address. NBU clients running 6.x release, though it uses the vnetd daemon for incoming connections, it still requires bpcd to perform the hostname compare to authenticate the NBU server. Troubleshooting: Below are steps you can use to help isolate the issue. When troubleshooting status 58 errors on a NetBackup client, the first thing to test is to whether or not you can access the client from the client Host Properties from the master server. If that works the same ports are involved when backing up the client as to when you access the client host properties. Connecting to the client host properties from the master server would prove the master server can access the client without any problems. So if using a storage unit on the master server you should be able to backup the client without getting the status 58 error. In 6.x environments you can use the command- bptestbpcd to verify you can connect to both the vnetd and bpcd ports on the client server. e.g. bptestbpcd -verbose -debug -client See the tech note 277901 for additional details on use of that command. http://entsupport.symantec.com/docs/277901 If still getting status 58 errors after ensuring the master server can connect to the client, focus on the media server used during the backup. The problem is more than likely with the client hostname lookup or gethostbyname call made to DNS or local host file on the media server. If the master server can not connect to the client when trying to access the client host properties, or the point of failure appears to be with the media server, below are steps you can take to further troubleshoot this issueTo test the master/media server resolution of the client server hostname run the following command/netbackup/bin/./bpclntcmd -hn
Status Code: 196 Client backup was not attempted because the backup window closed

Page 7 of 18

Since reverse lookups is part of the NBU server to client connections make sure the client can also be resolved by its IP address/netbackup/bin/./bpclntcmd -ip On the client test the resolution of the NBU servers by issuing the same commands. These commands should be run against all of the media servers that may be trying to backup the client server/netbackup/bin/./bpclntcmd -hn /netbackup/bin/./bpclntcmd -ip Verify you are able to "ping" the client's IP address from the NBU server. If this fails consult with your Network Administrator and client server System Administrator to resolve the layer 3 or IP network connectivity. Double check the server's NIC's IP address and netmask to ensure they are configured correctly. A very useful command to help with testing client and server resolution is the command bpclntcmd -pn when run from a NBU client or media server. What that command does when ran on a client as example, 1. The client gets the first server listed in it's server's list and knowing it is the master server does a forward lookup of that hostname or a gethostbyname call to DNS or host file. 2. Once that is successful you should see the message-"expecting response from (master server hostname)". If the forward lookup fails or the client does not have the bprd port 13720 defined in the registry for Windows clients or in /etc/services for UNIX clients you will not see that message displayed. Create a bplist log on the client at verbose 5 and rerun that command. 3. When the client connects to the bprd port on the master server, the master server performs two functions. It first does a simple reverse lookup of the incoming IP address and that is the first name returned by the command. Then it goes into the policy database and lookup what hostname it is using when backing up the client server. That is the second hostname returned by the command. See the example belowIn this example the client hostname is dotto.veritas.com and the master server is hal9000.veritas.comC:\Program Files\VERITAS\NetBackup\bin>bpclntcmd -pn expecting response from server hal9000.veritas.com dotto.veritas.com dotto.veritas.com 10.82.110.6 3412 Creating a bplist log on the client at verbose 5 should show the attempt to resolve the master server and make a connection request to the NBU server. Creating a bprd log on the master server should show the incoming connection as well. The same bprd log when create on the master server would show the attempt to connect to the client using the client host properties.
Status Code: 196 Client backup was not attempted because the backup window closed

Page 8 of 18

Resolution: The next step if the client is still failing with a status 58 after you verified the servers are resolvable to each other using the bpclntcmd command, is to ensure the client server has the bpcd port in listening modeFor Windows clientsnetstat -a and look for the BPCD and VNETD port are listeninge.g. TCP dotto:vnetd dotto.veritas.com:0 LISTENING TCP dotto:bpcd dotto.veritas.com:0 LISTENING For UNIX client verify the ports are listening by issuing the same command# netstat -a |grep bpcd *.bpcd *.* 0 0 49152 0 LISTEN #netstat -a |grep vnetd *.vnetd *.* 0 0 49152 0 LISTEN For Windows clients if it not listening on the ports verify bpinetd is running on the client using task mgr. For UNIX clients verify BPCD and VNETD are defined in /etc/service and inetd# vi /etc/services bpcd 13782/tcp bpcd vnetd 13724/tcp vnetd # vi /etc/inetd.conf bpcd stream tcp nowait root /usr/openv/netbackup/bin/bpcd bpcd vnetd stream tcp nowait root /usr/openv/bin/vnetd vnetd For UNIX client server if the /etc/services file for bpcd shows it is using tcpd then there is a TCP wrapper on the bpcd port 13782This example shows a TCP wrapper running on the bpcd port when defined in inetd.confbpcd stream tcp nowait root /usr/local/bin/tcpd /usr/openv/netbackup/bin/bpcd bpcd Locally on the client create a bpcd log and increase the verbose level to 5. On the client server to test whether the bpcd binary is executable and will generate a log issue the following commandUNIX- netbackup/bin/./bpcd Windows- program files\VERITAS\netbackup\bin:bpcd
Status Code: 196 Client backup was not attempted because the backup window closed

Page 9 of 18

That should generate the following log entry and prove the binary is executable and generates a log entryBPCD log. You should see something like this 16:47:45.986 [5296.3376] <2> bpcd main: offset to GMT 21600 16:47:45.986 [5296.3376] <2> bpcd main: Got socket for input 3 16:47:46.017 [5296.3376] <2> logconnections: getsockname(3) failed: 10038 16:47:46.017 [5296.3376] <16> bpcd setup_sockopts: setsockopt 1 failed: h_errno 10038 16:47:46.017 [5296.3376] <2> bpcd main: setup_sockopts complete 16:47:46.158 [5296.3376] <2> vauth_acceptor: ..\libvlibs\vauth_comm.c.332: Function failed: 17 0x00000011 16:47:46.158 [5296.3376] <16> bpcd main: authentication failed: 17 It is normal to have it end with the <16> bpcd main: authentication failed: 17 error. But this test proves the binary is functioning correctly. Then to test the bpcd port locally on the client server from the command prompt, run this telnet test using the loopback interfacetelnet localhost 13782 or telnet 127.0.0.1 13782 That telnet to the loopback interface using the localhost hostname should generate a log that looks like this16:49:35.352 [3336.4360] <2> bpcd main: offset to GMT 21600 16:49:35.352 [3336.4360] <2> bpcd main: Got socket for input 376 16:49:35.352 [3336.4360] <2> logconnections: BPCD ACCEPT FROM 127.0.0.1.3845 TO 127.0.0.1.13782 16:49:35.352 [3336.4360] <2> bpcd main: setup_sockopts complete 16:49:35.414 [3336.4360] <2> bpcd peer_hostname: Connection from host localhost (127.0.0.1) port 3845 16:49:35.414 [3336.4360] <2> bpcd valid_server: comparing hal9000.veritas.com and localhost 16:49:35.414 [3336.4360] <4> bpcd valid_server: localhost is not a master server 16:49:35.414 [3336.4360] <16> bpcd valid_server: localhost is not a media server either 16:49:39.189 [3336.4360] <16> bpcd main: read failed: The operation completed successfully. It generates the <16> error because it does not understand what telnet is and also fails to authenticate the localhost as a NBU server. For Linux clients if they are missing a library file required by bpcd or vnetd you would get this type of error messagetelnet localhost bpcd
Status Code: 196 Client backup was not attempted because the backup window closed

Page 10 of 18

Trying 127.0.0.1... Connected to clientname.domainname.com Escape character is '^]'.


bpcd: error while loading shared libraries: libstdc++-libc6.2-2.so.3: cannot open shared object file: No such file or directory

Contact the OS vendor to obtain the required library file. If the telnet to localhost works try the same telnet test from the master server using the client hostname to the bpcd porttelnet (client hostname) 13782

That should generate a log entry as seen below showing the master server being accepted16:52:46.077 [1160.5436] <2> bpcd main: offset to GMT 21600 16:52:46.077 [1160.5436] <2> bpcd main: Got socket for input 400 **The client sees the incoming connection from the master server using the IP address 10.82.105.254** 16:52:46.077 [1160.5436] <2> logconnections: BPCD ACCEPT FROM 10.82.105.254.44554 TO 10.82.110.6.13782 16:52:46.077 [1160.5436] <2> bpcd main: setup_sockopts complete **Performs a reverse lookup of the incoming IP address and gets the hostname** 16:52:46.092 [1160.5436] <2> bpcd peer_hostname: Connection from host hal9000.veritas.com (10.82.105.254) port 44554 **Then compares the hostname to the server list on the client** 16:52:46.092 [1160.5436] <2> bpcd valid_server: comparing hal9000.veritas.com and hal9000.veritas.com **The hostname compare succeeds** 16:52:46.092 [1160.5436] <4> bpcd valid_server: hostname comparison succeeded 16:52:49.476 [1160.5436] <16> bpcd main: read failed: The operation completed successfully. If any of these telnet tests fails to generate a log entry then there is something outside of NBU that is preventing access to the client's port. Most likely firewall software or a TCP wrapper was placed on the ports. Checking what services the client is running for Windows clients (Try Turning off MS firewall software for a quick test) or check the host.allow/deny files on the UNIX clients would be a good place to review next. For UNIX clients you can try removing the BPCD port from inetd.conf and run the command "bpcd -standalone" to see if that gets the port listening. Note: When testing connections to bpcd note the delta time difference between the bpcd log message e.g. "16:52:46.077 [1160.5436] <2> logconnections: BPCD ACCEPT FROM 10.82.105.254.44554 TO 10.82.110.6.13782 " and the log message "16:52:46.092 [1160.5436] <4> bpcd valid_server: hostname comparison succeeded" Due to the hard coded bprbm timeout of 1 minute this time difference can not exceed 60 seconds. If it exceeds that timeout then try using a host file entry to avoid DNS latency.
Status Code: 196 Client backup was not attempted because the backup window closed

Page 11 of 18

If the client had been working at NBU 5.x release but now fails after upgrading to NBU 6.x, you can try using 5.x defaults for the client connection to see if that gets the failing client working again. To do so, from the Administration Console: 1. Launch the NetBackup Administration Console, connecting to the master server 2. Expand Host Properties in the left pane 3. Select Master Server in the left pane 4. Click the name of the master server in the right pane 5. Select the Client Attributes section 6. Add the name of the client in question if it isn't listed 7. In the Connect Options tab for the client, make the following changes: BPCD connect back -> "Random port" Ports -> "Reserved port" Daemon connection port -> "Daemon port only" Note: You DO NOT have to stop and restart when making changes to the master server client attribute tab. Just simply click apply and okay to commit those changes. If unable to resolve this issue place a call to Symantec Technical Support for NetBackup for help in troubleshooting this issue.

Status Code: 59
Access to the client was not allowed
The access to the client was not allowed error indicates that the Master or Media server is trying to access the client, but is not recognized by that client as a valid server. When a backup starts, the clients bpcd process performs a gethostbyaddr() on the incoming connection's remote IP address, which retrieves the server name. This returned name is then compared against the hostname(s) specified in the clients Server list. If there is a match, the remote host is seen as a valid server. If the hostnames don't match, the host connecting to the client is not viewed as a valid NetBackup server and isnt allowed to start the backup (Status 59). This document reviews the 2 cases in which this error can occur.

Status Code: 196 Client backup was not attempted because the backup window closed

Page 12 of 18

Status Code: 196 Client backup was not attempted because the backup window closed

Page 13 of 18

Table of Contents
3 1 Managing Backup Policies and Storage Units.......................................................................................... 3

1.1 Policy Configuration..............................................................................................................3 1.1.1 Maximum Jobs per policy and client..............................................................................3 1.1.2 Additional Features/Options...........................................................................................4
2 Optimizing Backup Performance.............................................................................................................. 4

2.1 Identify Bottlenecks...............................................................................................................4 2.2 Multiplexing...........................................................................................................................5 2.2.1 Multiplexing - Planning..................................................................................................5 2.2.2 Multiplexing - Implementation.......................................................................................5 2.3 Eliminate Unnecessary Logging............................................................................................5
3 Verify hardware availability....................................................................................................................... 6 4 NetBackup Scheduler (bpsched) delays due to environmental problems.................................................6

4.1.1 Troubleshooting Status Code 58 ....................................................................................7


1 Server is not listed within the Clients Server list.....................................................................................15 2 Name Resolution.................................................................................................................................... 16

2.1 Multiple Nics.......................................................................................................................17 2.2 Fully Qualified Domain Names ....................................................................................................................................................17


3 Further Log Examination...................................................................................................................... 18

Status Code: 196 Client backup was not attempted because the backup window closed

Page 14 of 18

1 Server is not listed within the Clients Server list


Verify that the NetBackup Master and Media Servers hostname is in the Server list on the client. The Master and Media Servers can be the same host. Follow the appropriate platform-specific instructions to verify the Master or Media Server name(s) in the Clients Server list. UNIX Clients Edit /usr/openv/netbackup/bp.conf file and ensure that there is a SERVER= line for any Master and Media Servers that connect to the client. The Master Server name should be the first SERVER entry in the clients server list, followed by an entry for whatever Media Servers will connect to the client. Example bp.conf excerpt:
SERVER = NBUMASTER SERVER = NBUMEDIA01

NetWare and OS/2 Clients The instructions for Netware and OS/2 are nearly the same. Add a SERVER entry in the Sys\openv\netback\bp.ini file as needed.

Windows Clients
Add server entries on Windows clients by doing the following: 1. Open the Backup, Archive, and Restore interface. 2. Select File > Specify NetBackup Machines and Policy Type. 3. Select the Servers tab. 4. Verify that the Master/Media Server(s) are added to this server list, and that the Master Server is set as current. 5. Click OK after adding any needed servers and exit Backup, Archive and Restore. Note: If server entries are modified on a NetBackup Master Server, it is necessary to stop and restart NetBackup services/processes. Services/processes do not need to be restarted on a Media Server or Client after updating the server list.

Status Code: 196 Client backup was not attempted because the backup window closed

Page 15 of 18

2 Name Resolution
Name resolution should be closely analyzed if the requesting server appears in the clients server list, but the Status 59 is still seen. In this case, the hostname comparisons made on the client between the server list and resolved host name are not matching.

Using bpclntcmd
bpclntcmd is a useful utility that can be run from any Client. It will help determine if name resolution is working properly from NetBackups perspective. Windows command location: %install_path%\VERITAS\NetBackup\bin\
UNIX command location: /usr/openv/netbackup/bin

Switches and variations:


bpclntcmd -pn bpclntcmd -self bpclntcmd -hn <hostname_of_masterserver> bpclntcmd -hn <hostname_of_mediaserver> bpclntcmd -hn <hostname_of_client> bpclntcmd -ip <ip_of_masterserver> bpclntcmd -ip <ip_of_mediaserver> bpclntcmd -ip <ip_of_client>

The goal of these commands is to make sure the hostname is consistently seen the same way after each command. Below is an explanation of what each switch does: -pn - The client process on the host connects to the Master Server and asks the question "Who am I?". The second line of the output is the result. This is how the client process on the host is being seen by the Master Server. -self - Checks how this host can be resolved. Ideally, there should be only 1 unique hostname and 1 unique IP address. -hn - Checks the given hostname and returns an IP. -ip - Checks the given IP and returns a hostname. If there is any inconsistency in the results of these commands, correct the hostname to IP resolution by either editing the local hosts table or by updating the DNS database.

Status Code: 196 Client backup was not attempted because the backup window closed

Page 16 of 18

2.1 Multiple Nics


If a NetBackup Master or Media Server has multiple interface cards, add the name of each network interface to the server list on the NetBackup client. Also, verify that the client can resolve the name and IP address for each functioning NIC on the Master/Media Server(s).

2.2 Fully Qualified Domain Names


In some cases, an IP is translated to the correct host, but the Fully Qualified Domain Name of the host. If a server connects to a client and the client translates the incoming ip to the Fully Qualified Domain Name (FQDN), then that FQDN host name must also be added to the server list. For example, suppose a machine called media-bk is trying to connect to a client for backup. On the backup request, the client translates the Servers IP to mediabk.mydomain.com. In this instance, if only media-bk is added to the server list, the backup will likely fail with a status 59. Both media-bk and mediabk.mydomain.com should be added to the server list. Hostname comparisons can be seen from within the bpcd log.
14:21:50.014 [3812.892] <2> bpcd main: offset to GMT 18000 14:21:50.014 [3812.892] <2> bpcd main: Got socket for input 336 14:21:50.024 [3812.892] <2> logconnections: BPCD ACCEPT FROM 10.66.16.116.2153 TO 10.66.14.22.13724 14:21:50.024 [3812.892] <2> bpcd main: setup_sockopts complete 14:21:50.064 [3812.892] <2> bpcd peer_hostname: Connection from host mediabk.mydomain.com (192.168.111.25) port 955 14:21:50.064 [3812.892] <2> bpcd valid_server: comparing media-bk and mediabk.mydomain.com 14:21:50.134 [3812.892] <4> bpcd valid_server: media-bk.mydomain.com is not a server 14:21:50.134 [3812.892] <16> bpcd valid_server: media-bk.mydomain.com is not a either 14:21:50.134 [3812.892] <2> bpcd main: output socket port number = 1 14:21:50.294 [3812.892] <2> bpcd main: Duplicated vnetd socket on stderr 14:21:50.294 [3812.892] <2> bpcd main: <---- NetBackup 6.0CA 0 ------------initiated 14:21:50.294 [3812.892] <2> bpcd exit_bpcd: exit status 46 ----------->exiting 14:21:50.294 [3812.892] <4> bpcd exit_bpcd: FTL - BPCD EXIT STATUS 46 14:21:50.294 [3812.892] <16> bpcd main: Server access denied

In the above situation, the Client was resolving the fully qualified name of the Media Server. This fully qualified hostname must be added to the server list for the backup to work.

Status Code: 196 Client backup was not attempted because the backup window closed

Page 17 of 18

3 Further Log Examination


If the Media Server name is in the clients server list and name resolution appears to be correct, enable logging on the client for further error detail. Increase logging verbosity UNIX Clients Increase the debug or log level by adding VERBOSE on a separate line at the end of the /usr/openv/netbackup/bp.conf file on the client. Windows clients Set the debug level on the Troubleshooting tab of the NetBackup Client properties dialog. To Open this dialog, start the Backup, Archive, and Restore interface and click NetBackup Client Properties on the File menu. Retry the backup and examine the resulting logs to determine the cause of the failure.

Status Code: 196 Client backup was not attempted because the backup window closed

Page 18 of 18

You might also like