odd "incorrect media found in drive index"

[brandonn]

I've got a very odd, and critical situation.

For absolutely no reason at all, all my backups stopped working with the error "incorrect media found in drive index x"

The obvious error seems to have an obvious solution, but i think there's something else going on here...

Error bptm(pid=8896) incorrect media found in drive index 13, expected 5920L3, found KR5920, FREEZING 5920L3

My tape barcode is KR5920L3

It is comparing the first 6 of the barcode to the last 6. Netbackup is pulling the correct tape and everything, however, when it tries to verify the tape it is comparing with opposite ends of the barcode label.

Nothing has changed in my configuration, so I have no idea why this is happening.

Anyone got any ideas?

[Yasuhisa_Ishika]

It seems that the tape with bacode KR5920L3 had been registered and used as KR5920, but at same time you delete this and Media ID Generation Rule, and ran Robot Inventory. To correct this, delete all suspicious media, add Media ID Generation Rule so as to generate media ID from first 6 characters of barcode ID, and run Robot Inventory.

[J_H_Is_gone]

One of the things I have found is that the id generation rule is saved and read from the server/pc that is running the console.

So say you normally run an inventory and inject new tapes via the console on the master. And it has a Media Id Generation rule.  All is fine.

Now you run the window remote admin console from your pc and do an inventory, injecting new tapes.  If you did not create a rule in the console on your pc, then you have no rule.

So things I would check.

that every server that can run the console has a media id generation rule setup ( so go vote for my idea to have it saved and read from the master)

check that the rule on your library is still setup correctly to send the correct barcode

check your media list to see if you have any more tapes that do not have the KR in front for the media id.

you will have to also bplabel the tape. As it seems it was once written to with the label of the last 6, which now does not match the barcode.

[brandonn]

I did try and delete all suspicious media (all 300 of them) and re-add them. Same error.

We only work the console from one server, so there is no MEDIA ID generation conflict.

Media ID generation rule: 1:2:3:4:5:6  it has always been this without fail before.

[J_H_Is_gone · Accepted solution]

If at some point the tape came in as 590L3

then it got written to with that id, meaning the beginging of the tape has 590L3 written on it.

When NB pulls a tape it checks that the barcode matches the Media id written on the beginging of the tape.

this is a safty issue in case your barcode falls off and you put it back on the wrong tape. Or if someone changes the barcode and the images on the tape are not really expired.

What you have to do to fix it is bplabel the tape.

So once you get the tapes into NB showing the correct barcode and media id.

Right click the tape.

Choose lable

uncheck the box that says check the id/barcode (as this is your issue)

it will the load the tape into a drive and re-write the id on the media to match what NB says the tape is called.

ONLY do this if you know all images on the tape have expired.

[Nicolai]

just a idea.

Did you have the firmware on the robot updated recently ?. I have seen examples where a firmware update have changed the robot reporting method to the host.

[brandonn]

Do you know of a command that could help me find all the discrepencies as well as possibly relabeling mass amounts of tapes? I've got a pretty good idea there are over 300 tapes with this problem.

Thanks for the information, very helpful.

[brandonn]

Yes actually. We upgraded the firmware about 2 months ago. Very odd that i'm just now getting a problem, and it's not with all tapes (only some) /confused

[J_H_Is_gone]

The only way to tell would be to see which tapes show the wrong media id in the GUI.

but if you have already fixed them so they show the correct one, I know of know way of finding out.

Just bplabel all your scratch tapes.  can you do it with the check mark and it will error if the written id does not match the media id, then those will have to be done.

But the only way to tell if they don't match is to mount them in a tape drive.  So doing the label is the only way to tell.

[Andy_Welburn]

Depends on what these discrepancies are I suppose - if you just want to compare all the media_ids & barcode labels then you could use vmquery. This is what I posted a fews days back on another thread:

"...
Maybe worthwhile

doing a vmquery -a -w & looking at all the media_ids & barcodes to see what you've got & what's not right.

e.g. vmquery -a -w | awk '{print $1,$4}'
..."

As far as re-labelling is concerned, as the media-ids are effectively wrong, personally I'd be tempted to delete the media once all the images on them have expired (if any), then re-insert them into the library & re-inventory ensuring any media-id generation is correct (including ensuring the robot/library presents the correct barcode to NetBackup as already suggested). I would also re-label manually in small(ish) batches, ensuring the check box for verifying label is un-ticked, as don't forget a tape drive is required to perform this! I suppose if you're happy that you can re-label 300+ tapes en-masse then there's nothing to stop you from compiling a list of the media to be labelled (vmquery again?) & feeding that into a bplabel command.

[Venkatesh_K]

Hi ,

you may need to delete the media from NB database and reinitialize them again.

im assuming these tapes were used by you earlier for backup and now your trying to use these medias with diffrent lable

1. bpexpdate -m XXXXX -d 0 -force

2. nbemmcmd -deletemedia -mediaid XXXXX -originhost NONE

3. Inventory the robot

4. bplabel -m XXXXXX -d <density> -host <media server >

[J_H_Is_gone]

You would only see the issue when ADDING NEW tapes to the robot that NB has never seen before.

So did you withing the last 2 months buy and put in new tapes?

And find that screen in the library config that tells it what part of the barcode to send to NB.

[Andy_Welburn]

If I remember correctly (& that's a big if!!), when we had a new robot installed, it presented the barcodes differently to NB & subsequently existing media were deemed to be new - could something similar be happening here?

[brandonn]

Thanks for all your help. While I cannot determine what caused this mismatch, I was able to correct the situation based on the response I got here.

I did a Label w/ Verify on all of my scratch tapes and it showed a good chunk of them had this wierd shift of barcode numbers. No tapes had wrong ID's, only skewed of the correct barcode.

To simplify things, I simply did a Label w/o Verify on chunks of 100 tapes at a time. Everything is now fine.