We take tapes out regularly, using a script that checks which tapes
aren't going to expire until a certain month.  When the script ejects
these, it changes the volume group for the tape to be the month name.
The tape then goes in the box similarly labelled with the month name.

When a restore requests a tape that is out of the library, the device
monitor (vmoprcmd -d pr) will show what volume group is allocated to it,
and hence which box it is in, so it can easily be found.

Of course this is still dependent on people putting the tapes in the
right boxes, and I've had problems with that :-) - it's great fun going
through all the boxes comparing the tapes with where NetBackup thinks
they are!

hope this helps... ours is all on UNIX & so possibly easier to script.

Phil

-----Original Message-----
From: veritas-bu-bounces at mailman.eng.auburn.edu
[mailto:veritas-bu-bounces at mailman.eng.auburn.edu] On Behalf Of WEAVER,
Simon
Sent: 09 November 2006 06:30
To: 'Darren Dunham'
Cc: Veritas-bu at mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Recognise Media from NBU



Darren
Ok to prevent any further confusion..........

Tapes are in an ESL Robotic Library WITH barcodes :-)

Now, each month at least 40 - 50 tapes are taken out of the library,
placed
in cases and stored in a safe.
On the outside case, they label the tape "MONTH XX" - So they know a
backup
was performed at the end of each month.

The trouble they appear to be having...... When a restore is needed from
a
month end tape, they have to go searching for the tape or tapes that are
needed.

Now. My argument to this would be to "Label the tape with the Month
number
PLUS the volume pool it came from" - for example if it's a file server,
the
volume would come from the "File_Server_Month_Pool" - However they
cannot do
this as it's a time consuming task.

Now, my other argument was to "start a restore" which would then say in
the
Activity Monitor "tape xxxxL3 required" - then they could load the tape.
I
thought this would be ok, but again seems to be a problem for them.

So.... My question was "Is there an EASIER method or command that could
be
used to identify what tape is needed for a restore BEFORE you actually
start
the restore"? If not, then I see 2 options:

1) Use Activity Monitor and when prompted, load the applicable tape or
tapes
2) Label the tape from the corresponding pool number

I should point out, this is not just a safe, its more like a vault with
THOUSANDS of tapes. Maybe the issue lies within the site (ie: better
organisation of tapes perhaps)? 

Anyhow, that was the question.... I may have answered it myself, but if
there is another easy method ?

Thanks

Regards

Simon Weaver
3rd Line Technical Support
Windows Domain Administrator 

EADS Astrium Limited, B23AA IM (DCS)
Anchorage Road, Portsmouth, PO3 5PU

Email: Simon.Weaver at Astrium-eads.net



-----Original Message-----
From: Darren Dunham [mailto:ddunham at taos.com] 
Sent: 08 November 2006 18:41
To: Veritas-bu at mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Recognise Media from NBU


> One of our libraries has over 40 tapes taken out each and every month 
> to be stored in a safe.
>  
> Trouble is, it is a time consuming process to label each tape (not 
> that I mind too much!).

But they do or don't have barcodes?  What type of label do you put on
the
tape?

> Anyhow, is there an EASY method or way to tell What data is on a tape 
> via a command line without the need to load the single tape into the 
> library?
>
> I could go through tapes one by one, but is there an easier method I 
> am overlooking?

I'm not sure I understand what information you want.  

What information goes on your labels?  Many sites just track all tapes
by
barcode.

There's lots of information to gather on the command line, but I
wouldn't
normally put it on the tape itself.

-- 
Darren Dunham                                           ddunham at taos.com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >
_______________________________________________
Veritas-bu maillist  -  Veritas-bu at mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

This email (including any attachments) may contain confidential and/or
privileged information or information otherwise protected from
disclosure. If you are not the intended recipient, please notify the
sender immediately, do not copy this message or any attachments and do
not use it for any purpose or disclose its content to any person, but
delete this message and any attachments from your system. Astrium
disclaims any and all liability if this email transmission was virus
corrupted, altered or falsified.
---------------------------------------------------------------------
Astrium Limited, Registered in England and Wales No. 2449259
Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS,
England
_______________________________________________
Veritas-bu maillist  -  Veritas-bu at mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

-----------------------------------------
Egg is a trading name of the Egg group of companies which includes:
Egg plc (reg no 2448340), Egg Financial Intermediation Ltd (reg no
3828289), and Egg Banking plc (reg no 2999842). Egg Banking plc and
Egg Financial Intermediation Ltd are authorised and regulated by
the Financial Services Authority (FSA) and are entered in the FSA
register under numbers 205621 and 309551 respectively. These
members of the Egg group are registered in England and Wales.
Registered office: Laurence Pountney Hill, London EC4R 0HH. 

This e-mail is confidential and for use by the addressee only. If
you are not the intended recipient of this e-mail and have received
it in error, please return the message to the sender by replying to
it and then delete it from your mailbox. Internet e-mails are not
necessarily secure. The Egg group of companies do not accept
responsibility for changes made to this message after it was sent.


Whilst all reasonable care has been taken to avoid the transmission
of viruses, it is the responsibility of the recipient to ensure
that the onward transmission, opening or use of this message and
any attachments will not adversely affect its systems or data. No
responsibility is accepted by the Egg group of companies in this
regard and the recipient should carry out such virus and other
checks as it considers appropriate.

This communication does not create or modify any contract.