Forum Discussion

NIKHIL234656595's avatar
14 years ago
Solved

media mismatch

i ran an inventory and i saw tha tapes is in scratch but there is a conflict.

Media id is not matching with the barcode label.

meedia id:NDLA

BARCODE: MCLABL1

 

What are the steps to corect this?

 

  • Yes, that is what I was trying to explain.

    There is a LOT of mis-understanding about NetBackup and tapedrive / llibraries.

    Two of the most important things to remember :

    First (before I get shot down ....)  - the following statements are meant to cover 99% of cases ... yes, there might be a bug etc ... but that is a lot lot less likely than some other cause, and as such, based on whatever evidence I see, I would not consider this until the most likey causes are eliminated.

    For the record, I have only ever seen 1 case of robtest not working that was caued by NBU, and you are very very unlikely to see this < (and then, only if you have ACSLS).  

    1.  Everything you see in robtest is sent from the robot.  If it is wrong it is a fault with the library, not NetBackup.  The ONLY bit of NetBackup that robtest uses is the <device file> to contact the library.

    As I mentioned, I wanted you to use robtest to see the barcodes, and then if necessary, configre them via the library.

    2.  NetBackup DOES NOT write to tape - ever.  The data is sent from NetBackup to the operating system.  Although NetBackup supplies the buffer size, it is the operating system that carries out the writes (and reads) from tape, as well as positioning.

    It is certainly possible however, for NBU to cause tape write fails etc ... as the buffer sizes / number buffers come into play, but these cases are failrly easy to spot.  Out side of this, there are very very few reasons for NBU to cause tape issues.   It is failrly safe to say that :

    Errors that mention 'ioctl' 

    Anything that mentions TAPEALERT 

    ASC/ ASCQ errors

    mt 'postion errors'  (eg. MTREW failed)

    'External event caued rewind'

    ... and many more.

     

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

    was written to attemt to get troubleshooting for various errors (listed in the TN) started in the right place - yes there are exceptions (and the TN mentions some) , but developing good troubleshooting skill means knowing where to start looking.

    I would estimate that the vast majority of tape/ library cases I deal with should never have been opened, as the cause is nothing to do with NBU.

    Just because NBU reports an error, DOES NOT mean Netbackup CAUSED the error.  

     

    Martin

  • The barcode is whatever the default of the library is.

    It is probably 8, if not set, but I do not know for sure.  The  default media id is the last 6 characters of the barcode.

    Before you ask, if the barcode is only 6 characters, or less, the defaultmedia id will be exactly equal to the barcode.

    I have given the steps ...  previously ...

     

    Inventory the robot > Update Volume config then select advanced options button

    (I think that by default, the 'Advanced Options' button is 'disabled'.  When you select the 'Update volume config' button, it is then possible to select the 'Advanced Options' button.  )

    Once you have pressed the 'Advanced Option' button, goto the media ID generation tab

    You then specify the robot number

    The actual length of the barcode as displayed by the robot 

    (run robtest and do s s to see how many charcters in the barcodes)

    Then you specify the actual rule

    Eg.Iif the barcode is AA1234L4 and you want 5 characters you specify 

    1:2:3:4:5  ( =  AA1234 )

    If you are not sure, actually go and look in the manuals, it is ALL explained in the NetBackup Admin Guides (part I and II)

     

    Martin

  • What is it set to at the moment - look in robtest, run 's s'

    Example:

    I run robtest, select TLD 0 and then run s s

     

     

    rdgv240sol22 # robtest
    Configured robots with local control supporting test utilities:
      TLD(0)     robotic path = /dev/sg/c0tw2101000d772420c8l0
      TLD(1)     robotic path = /dev/sg/c0tw2103000d77640cc8l0
      TLD(2)     robotic path = rdgf270c-01:mc0
     
    Robot Selection
    ---------------
      1)  TLD 0
      2)  TLD 1
      3)  TLD 2
      4)  none/quit
    Enter choice: 1
     
    Robot selected: TLD(0)   robotic path = /dev/sg/c0tw2101000d772420c8l0
     
    Invoking robotic test utility:
    /usr/openv/volmgr/bin/tldtest -rn 0 -r /dev/sg/c0tw2101000d772420c8l0
     
    Opening /dev/sg/c0tw2101000d772420c8l0
    MODE_SENSE complete
    Enter tld commands (? returns help information)
    s s
    slot 1 (addr 1024) contains Cartridge = yes
    Source address = 131
    Barcode = DE0024
    slot 2 (addr 1025) contains Cartridge = yes
    Source address = 128
    Barcode = DE0173
     
     
    We see some slots, and the library shows the barcode of 6 characters.
     
    If you wish to change this, you need to consult with the library support people, it will be a setting somewhere on the library, but exactly how you do it is different across different makes and models.
     
    BUT ...
     
    Why do you want to change it, is it not ok as it is.
     
    Martin
  • thanks martin.

    I got my answer.

    We cannot do barcode change from NBU console.It is done by library support people.

  • Yes, that is what I was trying to explain.

    There is a LOT of mis-understanding about NetBackup and tapedrive / llibraries.

    Two of the most important things to remember :

    First (before I get shot down ....)  - the following statements are meant to cover 99% of cases ... yes, there might be a bug etc ... but that is a lot lot less likely than some other cause, and as such, based on whatever evidence I see, I would not consider this until the most likey causes are eliminated.

    For the record, I have only ever seen 1 case of robtest not working that was caued by NBU, and you are very very unlikely to see this < (and then, only if you have ACSLS).  

    1.  Everything you see in robtest is sent from the robot.  If it is wrong it is a fault with the library, not NetBackup.  The ONLY bit of NetBackup that robtest uses is the <device file> to contact the library.

    As I mentioned, I wanted you to use robtest to see the barcodes, and then if necessary, configre them via the library.

    2.  NetBackup DOES NOT write to tape - ever.  The data is sent from NetBackup to the operating system.  Although NetBackup supplies the buffer size, it is the operating system that carries out the writes (and reads) from tape, as well as positioning.

    It is certainly possible however, for NBU to cause tape write fails etc ... as the buffer sizes / number buffers come into play, but these cases are failrly easy to spot.  Out side of this, there are very very few reasons for NBU to cause tape issues.   It is failrly safe to say that :

    Errors that mention 'ioctl' 

    Anything that mentions TAPEALERT 

    ASC/ ASCQ errors

    mt 'postion errors'  (eg. MTREW failed)

    'External event caued rewind'

    ... and many more.

     

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

    was written to attemt to get troubleshooting for various errors (listed in the TN) started in the right place - yes there are exceptions (and the TN mentions some) , but developing good troubleshooting skill means knowing where to start looking.

    I would estimate that the vast majority of tape/ library cases I deal with should never have been opened, as the cause is nothing to do with NBU.

    Just because NBU reports an error, DOES NOT mean Netbackup CAUSED the error.  

     

    Martin