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.
From:
veritas-bu-bounces AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of William
Brown
Sent: Friday, January 15, 2010 8:05 AM
To: VERITAS-BU AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] LTO tape label / sequence?
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
From:
veritas-bu-bounces AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of J.Keating AT tachi-s DOT com
Sent: 14 January 2010 21:12
To: VERITAS-BU AT mailman.eng.auburn DOT edu
Subject: [Veritas-bu] LTO tape label / sequence?
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.
-----------------------------------------------------------