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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of WEAVER, Simon Sent: 09 November 2006 06:30 To: 'Darren Dunham' Cc: Veritas-bu@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: [EMAIL PROTECTED] -----Original Message----- From: Darren Dunham [mailto:[EMAIL PROTECTED] Sent: 08 November 2006 18:41 To: Veritas-bu@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 [EMAIL PROTECTED] 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@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@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. _______________________________________________ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu