Tape Mismatch (Netbackup thinks tapes in drives are not part of library)

it looks like your Master server is victim of media labeling,.

does the tapes that you insert are new tapes.. and have barcode labeled?

or old reused tapes?

how you are managing barcode rules in your master server envirornment?

show us the detail errors messages that you are reciving....

Please tell us how exactly you are ejecting and inserting media in the robot?

What is the model name/number of your IBM robot?
Does your robot have a MAP (media access port)?

If you are using the eject facility in NBU, the robot as well as NBU will be updated.

If you are inserting the new tapes via the MAP and use NBU inventory to 'Empty MAP before updating', then NBU sends the message to the robot to move tapes into empty slots.
It is not NBU that decides where the tapes must go - it is the robot that makes this decision.

If you are using above method to eject and insert media and tapes are going into the wrong slots, there is something wrong with your robot. Log a call with your hardware vendor.

I have only ever seen these kind of errors where operators were opening the robot door to insert tapes manually.

I'm going to guess this is a IBM 3584 series library ...

How many times have I seen similar issues like this with this library, lots and lots ...

The bad news, is that NetBackup is not selecting the slots to put the tapes in, the library is doing that.  This is almost certainly nothing to do with NBU, and nothing can be done in NBU to resolve it.

From your wording :

"Lately, whenever we run an inventory to insert the new tapes, the slots chosen by netbackup to insert them"

I think you are adding the tapes into the MAP/ CAP.

If ...

1.  You are adding the tapes to the MAP

2.  You have powercycled the library, and then run an inventory in NBU

and after this the issue still remains ...

There is not much else you can do, apart from call IBM.

There are some settings on the IBM libraries that can cause havic with NBU (or any other backkup software), but I've personally only seen these config issues cause slots to be non-visible.

This TN:

http://www.symantec.com/docs/TECH169477

explains that library invontary issues are outside of NBU.  I appreciate that the TN does not cover your exact issue, you will have to trust me.

The way it works is like this, despite what anyone else may say.

When running an inventory, NBU sends scsi commands to the library to start the inventory/ empty CAP.

What happens after that, is decided only by the library.

What is seen in NBU (eg where the tapes end up) is only sent back from the library, NBU has no control over this at all.

Hope this helps,

Martin

Sounds about right. I think your library isn't doing it's audit correctly or you have tape labels that don't match the internal tape label. Call IBM.

Great input, thanks guys. I'm reading up on some IBM issues (it's a TS3310 Tape Library) but what has me baffled is my way of fixing it temporarily...

1) When doing an inventory after removing/adding tapes into Netbackup, I notice the inventory changes proposed are conflicting with each other:

Logically move media ID AAAAAA from slot 111 to standalone residence

Logically move media ID BBBBBB from slot 222 to standalone residence

Logically move media ID CCCCCC from standalone to slot 333

Logically move media ID DDDDDD from standalone to slot 111

Logically move media ID EEEEEE from standalone to slot 222

So, the first 2 lines suggest moving tapes from slots to outside the library, and the 3 next lines are new tapes I've added. The problem is that the 2 first tapes, A and B, are not in those slots, but are in fact in drives, currently being written. Netbackup ignores them and decides to assign their reserved slots (empty yes, but assigned to them) to new tapes. When those jobs finish, the tapes are ejected but the slots are assigned to new tapes, so netbackup downs the drive and leaves the tape in the drive. I have to manually select the tape in IBM and remove it, then assign it to a whole new slot.

A bit more about my choice of words:

New Tape = tape that was previously ejected, 99.9% of the time sent to a storage facility outside the building for a month. Sorry, I didn't mean an actual new tape with new label - these are tapes Netbackup already knows and has already labelled.

Barcode rules are managed by Netbackup using our policies - doesn't seem to be the issue.

We always select "empty MAP" when running inventory. We manually eject tapes and send them outside the building, and then manually insert tapes. Inventory every time...

If it is in fact the IBM robot that chooses which slots to put them in, then again, wow. I'll have to run some tests later today/tomorrow and see how it behaves first-hand.

Thanks again for the replies, I will get back with more info soon!

>>The problem is that the 2 first tapes, A and B, are not in those slots, but are in fact in drives, currently being written. Netbackup ignores them and decides to assign their reserved slots (empty yes, but assigned to them) to new tapes.

As Martin states above "What is seen in NBU (eg where the tapes end up) is only sent back from the library, NBU has no control over this at all."

You will need to engage IBM support.  The library assigns slots for the media not NetBackup.  The library seems to be forgetting the media in the drives will return to respective slots.

"If it is in fact the IBM robot that chooses which slots to put them in, then again, wow. I'll have to run some tests later today/tomorrow and see how it behaves first-hand."

It is, I promise you ...

Despite 'very' popular opinion, including that of certain hardware vendors,  Netbackup actally has very very little to do with tape drives/ robots.

It does not write, or read from tape for a start, the actual write /read to a tape is carried out by the OS.

For inventories, loading, unloading drives, these are simple scsi commands sent to the library, what happens after the scsi command is sent, is 100% out of NBUs control.

Sure, if the NBU config is wrong this will cause issues, but the vast majority of tape and library issues are outside of NBU, and anything related to a TAPE_ALERT or ASC/ ASCQ errrors are 100% outside of NBU (apart from perhaps the cleaning tape alert if NBU is meant to be cleaning but has incorrect config for the cleaning tapes).

M

Just wanted to double double check how you load tapes (though it does sound like the infamous IBM library issue)

Do you only put tapes into the mail slot (load port or what ever you want to call it) or do the operators open the doors / magazines and insert tapes into empty slots?

I have had a lot of customers that have loaded tapes into empty magazine slots not realizing that it that empty slot belongs to a tape in a drive it cannot then be unloaded as it belongs to that slot.

Just wanted to be sure of your process when loading tapes

Actually we load tapes through the i/o door - the arm then loads them into a free slot (well, free as in empty but it looks like it's choosing the wrong slots)

Just an update - we're using Netbackup Vault now to do auto-ejects, which are fine. It's the loading part (and inventory) which just looks like it's trying to load tapes into taken slots (the taken slots are taken by tapes currently being written, everytime)