William,

 

We have seen this extra label checking on a unix (solaris) master also. With our master at 6.5.3 it is not quite so pretty.

 

I believe that there are several known methods for the serial number that comes from the tape cart and the serial number recorded in the netbackup data base to be different.

One method report by netbackup tech support is if a tape is moved out of a tape drive before all the label and other beginning processing has finished and replaced with another tape.

I suspect that there is another method caused by a netbackup bug, but we have not been able to find and document the situation.

 

Assuming we are talking about a scratch tape, a fix is to do a quick erase or label of the tape. This will reset the volser/serial-number data in netbackup’s database.  

 

 

I was quite surprised to find that NetBckup is not just looking at the tape label, but also what I think is the cartridge serial number with LTO.  I guess that comes from the LTO-CM.  This is 6.5.4

 

This happened on a Windows Master/Media server in our test lab:

 

20:00:48.922 [3908.1968] <2> openTpreqFile: tpreq_file: D:\Program Files\VERITAS\NetBackup\db\media\tpreq\drive_Drive1, serial_num: HU10606CNF

20:00:48.922 [3908.1968] <2> get_drive_path: SCSI coordinates {5,1,1,3}, dos_path \\.\Tape1, pnp_path \\?\scsi#sequential&ven_hp&prod_ultrium_3-scsi&rev_g54w#4&2b40ae32&0&113#{53f5630b-b6bf-11d0-94f2-00a0c91efb8b}

20:00:48.922 [3908.1968] <2> check_serial_num: serial number match for drive with SCSI coordinates {5,1,1,3}, dos_path \\.\Tape1, drive serial number HU10606CNF, expected serial number HU10606CNF

20:00:48.954 [3908.1968] <2> init_tape: \\.\Tape1 (SCSI coordinates {5,1,1,3}) configured with blocksize 0

20:00:48.954 [3908.1968] <2> init_tape: \\.\Tape1 (SCSI coordinates {5,1,1,3}) has compression enabled

20:00:48.969 [3908.1968] <2> io_open: SCSI RESERVE

20:00:49.391 [3908.1968] <2> manage_drive_attributes: report_attr, fl1 0x00000429, fl2 0x00000004

20:00:49.391 [3908.1968] <4> manage_drive_attributes: expected manufacturer [HP], reported [HP]

20:00:49.391 [3908.1968] <4> manage_drive_attributes: expected serial number [E63YABQ480], reported [1120653908]

20:00:49.391 [3908.1968] <2> send_MDS_msg: MEDIADB 1 1534 000013 4000113 *NULL* 20 1262980800 0 0 0 0 0 0 3 2 0 17 1024 0 0 0

20:00:49.391 [3908.1968] <16> manage_drive_attributes: FREEZING media id 000013, Medium identifiers do not match

20:00:49.391 [3908.1968] <2> io_close: closing D:\Program Files\VERITAS\NetBackup\db\media\tpreq\drive_Drive1, from bptm.c.18660

2

 

So I’d suggest, don’t reuse barcodes.

 

William D L Brown

 

 

Hello,

The question of "should we be paying particular attention of tape labels" question reared it's ugly head for me once again and I can't remember the answer.

Am I correct to believe that NBU won't import or confuse itself or the database if we should put a tape in the robot which has the same label as a tape that's has already been written too and cataloged?
And, should I be ordering labels with an existing sequence?


Regards,
John Keating
Information Technology
Tachi-S Engineering U.S.A. Inc.

-----------------------------------------------------------

This e-mail was sent by GlaxoSmithKline Services Unlimited 

(registered in England and Wales No. 1047315), which is a 

member of the GlaxoSmithKline group of companies. The 

registered address of GlaxoSmithKline Services Unlimited 

is 980 Great West Road, Brentford, Middlesex TW8 9GS.

-----------------------------------------------------------