Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

media ID not unique in database (34)

Created: 23 May 2012 | 21 comments

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

Comments 21 CommentsJump to latest comment

Will Restore's picture

Check this technote for possible solution:

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



 

 

Will Restore -- where there is a Will there is a way

Marianne's picture

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.

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

J.H Is gone's picture

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.

 

 

I don't have to know how to spell....I work on Unix.
NetBackup 7.0.1 - AIX & Windows

rizwan84tx's picture

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!

Best Regards,

Rizwan

dosdroit's picture

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's picture

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.

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

dosdroit's picture

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

Marianne's picture

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??

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

dosdroit's picture

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)

 

Yogesh9881's picture

what is the meaning of "Bonjour" blush

If this post has helped you, please vote or mark as solution.

Before break-up, make sure you have a good backup.....  ;-)

Will Restore's picture

literally 'good day'

 

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

Will Restore -- where there is a Will there is a way

Andy Welburn's picture

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

dosdroit's picture

because it's right dos droit means back straight

Ciao

Will Restore's picture

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

Will Restore -- where there is a Will there is a way

Will Restore's picture

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? 

 

Will Restore -- where there is a Will there is a way

dosdroit's picture

Hi,

Yes I did. But this is not the issue.

Thanks

Soap Raj's picture

 

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's picture

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/med...

as well as Rizwan's post: https://www-secure.symantec.com/connect/forums/med...

vmcheckxxx output will confirm!

 

 

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

dosdroit's picture

Bonjour all,

Thing are going bad here as we lost our library.

Marianne you are right about the situation

Honnestly I will look deeper in Bill's solution with the replacement library.

I will post next week, when the library has been replaced.

The broken library is out of warranty and the robot inside it is broken.

Stay tuned folks ;-)

Will Restore's picture

Hope you get that resolved quickly. 

 

 

 

Will Restore -- where there is a Will there is a way