Professional Documents
Culture Documents
Status
Code 213
NO YES
Is Go to Section 1.2
the storage unit of this technote
NO
correctly
configured?
YES
Go to Section 1.3
Are there down of this technote
YES
drives?
NO
Go to Section 1.4
Is BPCD listening? NO of this technote
YES
NO
NO
Contact Veritas
Technical Support
Windows - <install_path>\VERITAS\Patch\
If the patch levels are not the same, and the servers are running binaries earlier than NetBackup 4.5 FP3,
bring the media server experiencing the status 213 to the same NetBackup patch level as the master
server.
1.3 Policy has Storage Unit set to “Any Available” and the Drives are
Down.
A status code 213 is returned for any policy where the policy’s storage unit is set to "Any available" and
there are no available drives. (A status code 219 is returned for any policy where the storage unit is
specified and there are no available drives.)
The bpsched log file shows the following, where rumpunch is the media server and policya is the policy
name:
Command line:
To determine the status of the drives, run the vmoprcmd command below on the media server in
question.
UNIX: /usr/openv/volmgr/bin/vmoprcmd –d
Windows: <install_path\VERITAS\volmgr\bin\vmoprcmd –d
GUI:
The drive status can also be viewed in the Java GUI or NetBackup Administration Console under
Media and Device Management > Device Monitor. Check the Control field for the drive and
confirm that it is not AVR, for drives in a robot.
Command line-
UNIX: /usr/openv/volmgr/bin/vmoprcmd –up <drive_index>
Windows: <install_path\VERITAS\volmgr\bin\vmoprcmd –up <drive_index>
GUI:
Drive status is viewed by selecting Media and Device Management > Device Monitor.
If the drive status is DOWN, the drive can be brought UP in the Java GUI or NetBackup
Administration Console under Media and Device Management > Device Monitor. Right-click on
the drive and choose Up Drive.
The system error logs on a UNIX media server are located at:
• Solaris: /var/adm/messages
• HP-UX: /var/adm/syslog/syslog.log
• AIX: syslog log is not turned on by default. Check /etc/syslog.conf file for location of *.debug
and *.error log file. If it is commented out (if there is a # in front of *.debug and *.error), syslog is
not recording errors at the OS level. To troubleshoot drive issues, turn on syslog logging. The
AIX’s errpt command can also be used to look for hardware errors.
• Linux: /var/log/syslog
• The system error logs on Windows media server are:
Event Viewer Application and System logs.
If the reason for the drives going down is not obvious, please contact the operating system manufacturer
and the drive manufacturer for additional assistance in troubleshooting the drive issues.
If bpcd is not listening, the bpsched log file shows something similar to:
Verify that the master server can communicate with the bpcd process on the server that has the storage
unit.
If it doesn't then check the /etc/services file and verify this line exists:
bpcd 13782/tcp bpcd
Also check /etc/inetd.conf for this line and make sure the path to bpcd is correct:
/usr/openv/netbackup/bin/bpcd bpcd
b. On a Windows server, from a command line, issue the following command and confirm a
connection is established:
telnet <media_server_name> 13782
Additionally, confirm the NetBackup Client Service is running on the media server, as this
confirms bpcd is running.
c. If bpcd is operating correctly, create bpsched and bpcd activity log directories and retry the
operation. Check the resulting activity logs for any failures.
Verify forward and reverse (by ip) host name resolution is working. One method of verification is to use
/usr/openv/netbackup/bin/bpclntcmd.
Please see the TechNote referenced below in the "Related Documents" section.
For example:
In an environment containing one shared drive, two jobs are submitted at the same time. After the two
jobs finish, a third job is submitted:
1. The first two jobs initially go active at the same time because the bpsched process sees the drive
as available and current jobs as 0.
2. The first job submitted goes active, reserves the drive, and runs to completion.
3. The second job submitted goes active, tries to mount the drive, sees the drive is busy and
continuously requeues with a status code 134 until the first job completes.
4. After first job has completed, second job goes active, reserves the drive, and complete.
After both jobs are DONE in the activity monitor BUT PRIOR TO UNMOUNTING DRIVE another job is
submitted. This job fails with a status code 213.
The reason the second job requeued with a status code 134 is that the first job was active. A status code
134 is reported if bptm tries to mount the drive and finds it busy.
The reason the third job fails with a status code 213 is the bpsched process sees the previous jobs as
finished so it queues the job. When querying the Storage Unit for an available drive, ltid reports back to
bpsched the drive is “in use”. The drive is considered “in use” because the tape has not been unloaded.
Since the drive is in use, the job fails with a status code 213.
The difference is the third job was not ACTIVE yet. Since the job was not active yet and was in the
queued state, it received a 213.
Over-commits apply to Windows as well as UNIX. There is a touch file that disables the over-commit
check. This empty file is placed on the Master server.
IMPORTANT NOTE: The oc_check_disable file should ONLY apply to SSO environments. In an SSO
environment, status 134 errors may periodically occur due to the fact that the drives are actually over
committed. It should be stressed the touch file oc_check_disable should ONLY be used in 4.5 pre-MP4
/ FP4 and in 5.1 for specific timing issues resulting in a 213 error instead of a 134 requeue. This file
should be removed if it has no positive affect on the problem, and it should be removed after an upgrade.