media ID not unique in database (34)

[dosdroit]

Bonjour,

I'm getting that error:

media ID not unique in database (34)

I know the tape is not unique it's coming from another robot, but from the same media server.

I can I avoid to delete the tape and redo the inventory for every tape I'm putting in that new robot ?

thanks

[Will_Restore]

Check this technote for possible solution:

Article URL http://www.symantec.com/docs/TECH62822

[revarooo]

<deleted>

[Marianne]

Did you use NBU to eject tapes from RobotA before putting into RobotB?

If not, just select tapes, right-click, Move, and choose Standalone.

Next, inventory RobotB.
This should move tapes from standalone to new location.

[J_H_Is_gone]

I know the tape is not unique it's coming from another robot, but from the same media server.

Does that mean you have 2 tapes witht the same BARCODE?

or is it just the issue that Marianne mentioned that you did not eject it correctly from the other robot?

You CANNOT have 2 tapes with the same BARCODE within the same MASTER/NB domain.

[rizwan84tx]

I get the same message in one of our NB domain. We get the error when we swap the tapes between the robotic library, and one of our barcode scanner has limitation, where it can read only first 6 characters (RobotA) and other scanner can read all 8 characters (RobotB).

Media Barcode: NB1234L4

Media ID Generation: 1:2:3:4:5:6 (for both robots)

On inventorying RobotA:

                                   Barcode: NB1234

                                   Media ID: NB1234

Now, i eject the tape and insert in RobotB:

                                   Barcode: NB1234L4

                                   Media ID: NB1234

When we swap the tapes between the robots, the barcode detected is different, but the Media ID (NB1234) is already present (not unique) in the Volume DB and hence the error message "media ID not unique in database (34)". This is the behaviour of NetBackup, so to overcome; instead of deleting, we use VMCHANGE command to change the media barcode prior inventorying the tapes which we swap.

Hope this helps you!

[dosdroit]

Bonjour all of you,

I do not have 2 tapes with the same BARCODE.

I will look into Mrs.van den Berg solution.

The problem it's a remote site and I do not use the CAP for ejection.

I just take off the whole drawers of my HP MSL6030 and my HP MSL6060.

One thing I did not said is, those tapes are a come back from Iron Mountain.

I do not take the tapes and switch them over from a library to another.

It's a tape with an image that expired and came back from Iron Mountain...

Thanks for you answers.

[Marianne]

NBU Admin guide I also explains that when media is moved between robots, the media should first be moved to Standalone as intermediate step. Inventory cannot do it in one step.

[dosdroit]

Bonjour,

I feel there is no solution.

Moving or deleting every tapes to switch them between robots is not very practical or convenient or fast.

Thanks

[Yogesh9881]

what is the meaning of "Bonjour" 

[Will_Restore]

literally 'good day'

as for meaning of 'dosdroit' well I'll leave that for someone else

[Andy_Welburn]

dos droit means "back straight" in French ( as far as Google translator is concerned! )

[Marianne]

I don't understand why you feel that move to Standalone is not an option? Simple matter of bulk-select, right-click, Move, standalone. Then Inventory once in new robot. How is that not a solution? If not, how do you intend going forward??

[dosdroit]

Re-Bonjour,

Maybe I'm not understanding your solution.

1. I recall scratch tapes from Iron Mountain (tapes that use to have an image but it's expired now)
2. I put thoses tapes into library #1 and library #2 (new one)
3. When I inventory library #1 everything is showing up.
4. When I inventory library #2 I'm getting that error:

media ID not unique in database (34)

with a tape number

1. looking into the media database the tape is unique and in scratch pool
2. right click the tape and delete it to redo the inventory and getting that error:

media ID not unique in database (34)

With a new tape number

Now what I understand is I should choose manually all the tapes I'm putting into the library and manually move them into the standalone library.

It's not something I want to do, taking note of all 50 tapes with all numbers that do not follow each others.

I do not know what I will do.

Maybe create a script that will deletes all the tapes that are in scratch pool.

But if I do I will not know what tapes to recall from Iron Mountain...

Misère de malheur !! (misery of sadness)

[dosdroit]

because it's right dos droit means back straight

Ciao

[Will_Restore]

Yes, that is the literal.  I find some other wacky interpretations as well.

[Will_Restore]

Maybe create a script that will deletes all the tapes that are in scratch pool.

But if I do I will not know what tapes to recall from Iron Mountain...

OK, if you know which tapes to recall, you can "move" those media per Marianne's suggestion.  They do not have to be physically in the library to do that logical "move". 

Did you verify library settings per my original post? 

[Soap_Raj]

If the Media ID is not Unique in Library. It is already having entry of the media in the Tape Library.

Remove the dummy entry with below command and do the inventory again.

1. Delete the volume DB entry
<install_path>\Program Files\Veritas\Volmgr\bin\vmdelete -m 000AA6.

[Marianne]

OK - let us try to understand....

Tapes are ejected/removed from Robot1 and Robot2 = Standalone?

Returned from offsite and inserted into robot - not always back in same robot, right?

If tapes that were previously in Robot1 are now inserted in Robot2 (or vice versa) you see this error?

Question:
how does Robot1 read tape labels?
how does Robot2 read tape labels?

If the two robots read and report labels differently, you will see this error.

Please do the following from cmd from both robots and show us output: This command is equivalent of 'Compare contents' in Inventory. (there are really 3 x's in command).

vmcheckxxx -rt <robot-type> -rn <robot-number> -rh <robot-host>

(command is in volmgr/bin)

I reckon we might be back at Bill;s first reply above: https://www-secure.symantec.com/connect/forums/media-id-not-unique-database-34-0#comment-7173161

as well as Rizwan's post: https://www-secure.symantec.com/connect/forums/media-id-not-unique-database-34-0#comment-7175481

vmcheckxxx output will confirm!

[dosdroit]

Hi,

Yes I did. But this is not the issue.

Thanks