Problem
Duplication of GRT images from Disk to Tape fail with status 191. Job Datail stated "database system error (220)".
Error
Application Log:
Job Detail:
4/9/2012 10:10:02 AM - Error bpduplicate(pid=8212) db_IMAGE() failed: database system error (220)
4/9/2012 10:10:02 AM - Error bpduplicate(pid=8212) Status = no images were successfully processed.
4/9/2012 10:10:02 AM - Error bpduplicate(pid=8212) Duplicate of backupid exchange_1333796892 failed, database system error (220).
4/9/2012 10:10:02 AM - Error bpduplicate(pid=8212) Status = no images were successfully processed.
4/9/2012 10:10:03 AM - end Duplicate; elapsed time: 00:18:54
no images were successfully processed(191)
Environment
NetBackup 6.5.3 to 7.1.0.2
Cause
Bpdbm has a hardcoded timeout of 5 minutes. When nblbc on the Exchange client is enumerating the GRT objects for duplication to create the catalogue entries for the duplicated image and it takes longer than 5 minutes, bpdbm will close nblbc’s socket and when nblbc tries to connect back, the socket is closed and nblbc crashes.
Solution
The formal resolution to this issue (Etrack
2425881) is included in the following release:
- NetBackup 7.1 Maintenance Release 3 (7.1.0.3)
There is no technote for this particular issue as this has only been observed within very few customer environments.
“bpclntcmd” is a useful utility that can be run from any host. It will help determine if name resolution is working properly from NetBackup’s perspective. Test bpclntcmd between hosts where problems exist. This is often between the Client and Media Server.
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_master server, media server, or client>
bpclntcmd -ip <ip_of_master server, media server, or client>
The goal of these commands is to make sure the hostname is seen the same way after each command with no errors. 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 the local 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 or errors in the results of these commands, it may be necessary to add a local host entry in the operating system (etc hosts file) for the host to ensure proper name resolution.
