Video Screencast Help

media ID not unique in database (34)

Created: 06 Dec 2012 • Updated: 21 Jan 2013 | 11 comments
This issue has been solved. See solution.

Following on from upgrading our two libraries (different sites) from LTO3 drives to LTO5 I've had a request to perform a restore using the old LTO3 tape originally from the other site.

I performed bpmedia -movedb to swop the tape between media servers like we normally do but when I inventory the robot to start using the tape it gives me the "media ID not unique in database (34)", it obviously is as nothings changed. The tape was removed from library several months ago using netbackup.

vmquery -m returns

================================================================================
media ID:              CRO954
media type:            1/2" cartridge tape (6)
barcode:               CRO954L3
media description:     ----
volume pool:           Backup (4)
robot type:            NONE - Not Robotic (0)
volume group:          ---
vault name:            ---
vault sent date:       ---
vault return date:     ---
vault slot:            ---
vault session id:      ---
vault container id:    -
created:               Thu Feb 23 14:24:53 2012
assigned:              Fri Mar 02 20:15:16 2012
last mounted:          Thu Mar 08 20:15:53 2012
first mount:           Sat Mar 03 05:22:15 2012
expiration date:       ---
number of mounts:      5
max mounts allowed:    ---
status:                0x0
================================================================================

The bar code rules for existing media are set to Default for both options.

Any ideas?

 

Comments 11 CommentsJump to latest comment

Andy Welburn's picture

How is the new library presenting barcodes to NetBackup?

Is it possible that it is only presenting the first 6 digits & so deems it to be 'new' media,. but then media_id is generated which equates to the original?

e.g.

orginal barcode CRO954L3 media_id CRO954

'new' barcode CRO954 media_id CRO954

 

***EDIT***

Sorry, just re-read - new drives not new library?

mph999's picture

media ID:              CRO954

media type:            1/2" cartridge tape (6)
barcode:               CRO954L3

 

If you look in robtest :

/usr/openv/volmgr/bin/robtest 

Select robot

s s

this will 'show slots'  - find CRO954, what is the barcode displayed as ?

It should come back as CRO954L3, but let us check to make sure.

You are correct, CR0954 is unique at the moment, but, when you try and inventory the tape back into the library, NBU is thinking it is a new tape, whose media id is calculated to be CO054, and hence it is reporting as being 'not unique' as if it adds it, it won't be.

The usual reason for this, is that for whatever reason, the library is telling NBU that the tape has a barcode, that is different to what we think it sohould be - at this level, NBU marks a tape as 'new' if it has a barcode that is not in the DB.

So if my library shows all 8 characters of the barcode, and the media id gen rul makes the media id as the first 6 characters we have this 

barcode / media id

AA1234L4 / AA1234

If I now set the library to display only 6 characters for the barcode we have this

AA1234 / AA1234

NBU would take this 2nd tape as a new tape (barcode is different), but because the media id works out the same (first 6 characters ) then NBU would refuse to add it, as due to the different barcodes, it would take it to be two separate tapes.

Martin

 

Regards,  Martin
 
Setting Logs in NetBackup:
http://www.symantec.com/docs/TECH75805
 
Marianne's picture

Please also show us a screenshot of failed inventory attempt.

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

Calzor_Suzay's picture

I think for some reason NBU considers the MediaID as CRO954 & Barcode as CRO954L3 originally but now as per the screenshot reads the barcode as CRO954 and considers it different to then add it and find it's not unique.

I noticed all the new LTO5 tapes are listed as MediaID BSN285 & Barcode BSN285 whereas all the old LTO3 tapes have the L3 on the end of the bar code.

The library when browsed directly shows the full 8 character bar code for both LTO3 & LTO5 tapes.

We haven't from memory changed any of the barcode or media ID generation settings, everything looks like it's set to 'Default', the MediaID generation is set for barcode length 8 and then 1:2:3:4:5:6.

cro954.JPG
Calzor_Suzay's picture

Btw robtest comes back with this:-

slot 1 (addr 4096) contains Cartridge = yes
Source address = 4096
Barcode = CRT264
 

Marianne's picture

You need to check your robot config - it used to report 8 characters, but since the upgrade it is reporting first 6 characters.

Check your robot documentation for instructions.

Changing robot config will be a lot easier than updating Barcodes in NBU for all tapes. You will need to run vmchange against each media id...

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

Yasuhisa Ishikawa's picture

I understand you have two tape with same identity field like CRO954L3(LTO3) and CRO954L5(LTO5). Right?
Now NetBackup is trying to add LTO5 with media ID that is same with that of LTO3 tape.

You have to make choice:

  • Option 1: Expire and delete LTO3 tapes before inventory, and add LTO5 tapes with same media id by running inventory.
  • Option 2: Manually add LTO5 tapes with other media id.
  • Option 3: Buy and label new barcode labels for LTO5 tapes so that NetBackup will add tapes with different media IDs.

Option 2 is not a good option, because you will confuse difference of media ID and barcode label. Option 3 ot Option 1 is better if possible.

Authorized Symantec Consultant(ASC) Data Protection in Tokyo, Japan

Calzor_Suzay's picture

Ok through digging about on the library under the partition settings there's a "return media identifier" which under different options dumps the L3, L5 identifier or moves it to the end etc, we can change the behaviour but obviously it'll screw what's in the library now and written to which is approx 80 tapes, I think we just need to use vmchnge to tweak the barcode.

mph999's picture

Yep, use vmchange to change the barcode to what the library is displaying it as - problem solved.

The trick to this, is understanding that what is displayed in the output of (robtest) s s is sent from the library, and has 100% nothing to do with NBU, and, that NBU only acts on what it is told by the library.

You have a good understanding, but many people believe that when NBU runs an inventory 'NBU looks' in the library, the is 100% wrong, NBU doesn't inventory anything ever , it asks the library, 'what do you have' and the NBU inventory is therefore displaying what it is told by the library.

Martin

 

Regards,  Martin
 
Setting Logs in NetBackup:
http://www.symantec.com/docs/TECH75805
 
Marianne's picture

Command to update barcode:

 

 vmchange -barcode <barcode> -m <media_id>
 
No idea what your OS or scripting abilities are, but easiest will be to save a list of media id's that need to be changed and then script vmchange to loop through the list.
 
 
 

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

SOLUTION
Calzor_Suzay's picture

Yeah it's all done, updated reinventoried and all working :)