287 errors on deferred eject fails after one port eject

[Scott_in_AZ]

We have been having this issue for several months now, we start a deferred eject, and after 24 tapes (1 IE port in the library), the vault eject operation fails with the error: "eject operation is waiting for available MAP elements of robot".   We remove the tapes and restart the eject again and it fails each time after ejecting 24 tapes to the IE station.  The nature of the error (Waiting) makes me think this is a netbackup issue.

- no tapes are in the IE port - it is empty.

- all the correct daemons/services are running on NBU - verified.

- The robot has no issues, and is able to eject the tapes.  We even tried a powercycle of the library to see if that clear it up.

- we perfomed a library inventory from NBU before the ejcts were started.

- there are no backups running on NBU or the library.

- Running:  NBU version 7.5.0.6, on Windows Server 2008R2, Quantum i2000 library, 10GB flex fabric networking, HP G8 media servers.

From my NBU detail status for the backup job:

8/13/2014 9:08:08 AM - vault waiting for global lock
8/13/2014 9:08:08 AM - requesting resource ch7sbak0900.NBVAULT.MAXJOBS
8/13/2014 9:08:09 AM - granted resource ch7sbak0900.NBVAULT.MAXJOBS
8/13/2014 9:08:10 AM - vault global lock acquired
8/13/2014 9:08:10 AM - begin Eject/Report
8/13/2014 9:08:10 AM - connecting
8/13/2014 9:08:10 AM - connected; connect time: 00:00:00
8/13/2014 9:08:11 AM - vault waiting for eject lock
8/13/2014 9:08:11 AM - requesting resource ch7sbak0900.VAULT_EJECT.LOCK_0
8/13/2014 9:08:11 AM - granted resource ch7sbak0900.VAULT_EJECT.LOCK_0
8/13/2014 9:08:12 AM - vault eject lock acquired
8/13/2014 9:09:02 AM - starting eject of 170 media
8/13/2014 9:15:24 AM - media ejected from robot.  Please empty MAP
8/13/2014 9:16:49 AM - eject operation is waiting for available MAP elements of robot
8/13/2014 9:26:28 AM - eject complete with status 287.  24 of 170 media ejected
8/13/2014 9:26:28 AM - vault eject lock released
8/13/2014 9:26:28 AM - vault global lock released
8/13/2014 9:26:38 AM - end Eject/Report; elapsed time: 00:18:28
vault eject failed(287)

Can you help?   I have not seen a solution to this issue in these forums...

[INT_RND]

This is a common error when you eject more tapes than you have I/O slots available.

1. Update your device mappings:

http://www.symantec.com/business/support/index?page=content&id=TECH55064

2. Use vmchange to get information about the robot:

http://www.symantec.com/business/support/index?page=content&id=HOWTO43755

Use a command starting with:

vmchange -res -robot_info -verbose

Please post the output of the vmchange command from the robotic control host.

[watsons]

Is it something like this:

You have 24 MAPs in library, the vault selects > 24 tapes to be ejected, it ejects the first 24 but instead of waiting for next batch (and MAPs to be emptied), it fails with error 287  ??

If that's the case, looks like a bug and you should call support to investigate.

[Scott_in_AZ]

Symantec or Quantum support?

I am also checking those device mappings and vmchange info - busy day.

[watsons]

Symantec support. I guess the robot can eject those 24 tapes physically (or manually by robtest), 

[Scott_in_AZ · Accepted solution]

What the problem ended up being was the catalog size at our site is a lot larger that the normal catalog size.  We have to go into the media list in NBU (the media that are in the Quantum i2000/i6000) and delete any scratch tapes that are not in the tape library and are also not offsite.  When we perform this each week, all the tape libraries eject all the weekly media to go offsite without interruption.

Netbackup should be able to handle this without a problem, or it should kick out an error message that indicates an issue with the catalog size.  I view this as a flaww in NBU 7.5.0.6.

Maybe this issue can be addressed in a future update release??    I bet a lot of sites experience the same issue and just ignore it and keep restarting the vault eject until it completes.  That can be a pain if you have a lot of media to eject each week and creates more work for the onsite backup technician.