Re: [Veritas-bu] Status 96 media allocation issues
[EMAIL PROTECTED] wrote: Still, all you should have to do is bpexpdate the tape number and the tape should be reusable. That has worked in the past. It just seems to be this one batch had problems. deassignbyid is a bit of a big hammer to use casually. I'd do: bpexpdate -d 0 -m tapenum -force ..then a... bpexpdate -deassignempty -m tapenum -force ..this'll make the tape available sooner.. I'll look into using these. The deassignbyid came up for a reason at some point. I think it was because a policy would pull a tape from the scratch pool and not the archive pool it was supposed to. It seems this was needed before it would let us move the tape from the archive pool. It's legacy and can probably be removed. I'll try the -force options with these and see how they do. Loaded every tape, then requested a new one? I've seen this on write-protected tapes and on physical drive errors. If it loads the tape, finds it unusable for some reason, it'll dump it and request a new one. Did some enthusiastic tape monkey write-protect all your tapes? I wondered about them being write protected because I wasn't sure how they may have been put into the boxes for Iron Mountain. I was told by the local guy that he verified the tapes are not write protected. It seems something still has the VSN recorded somewhere or something like that. The local person had some blank tape labels. When he put them on the tapes and scanned them into the library, everything was fine. The nightly backups started using them. It isn't the ideal solution but it works for now. I'm out of town working on another project and will try and re-visit this next week sometime. Thanks for all the help. Jeff ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Status 96 media allocation issues
Still, all you should have to do is bpexpdate the tape number and the tape should be reusable. deassignbyid is a bit of a big hammer to use casually. I'd do: bpexpdate -d 0 -m tapenum -force ..then a... bpexpdate -deassignempty -m tapenum -force ..this'll make the tape available sooner.. It's cleaner and you're not stomping about in the database with big boots. By the way, bpexpdate has a -force option that expires the tape without asking confirmation - no need to echo y into it. Loaded every tape, then requested a new one? I've seen this on write-protected tapes and on physical drive errors. If it loads the tape, finds it unusable for some reason, it'll dump it and request a new one. Did some enthusiastic tape monkey write-protect all your tapes? -M -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Cleverley Sent: Monday, March 17, 2008 9:08 AM To: Paul Keating Cc: veritas-bu@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] Status 96 media allocation issues Paul, As mentioned, I only inherited the environment :-) I was told that the reason this was being done was they wanted to have the tapes and sessions protected until they decided to explicitly unprotect them. I think it stemmed more from paranoia and lack of understanding from the business. It is a bit of a make work thing. Jeff Paul Keating wrote: Why would you not set your retentions correctly (ie, set to expire when you want them to) then have Iron Mountain automatically return the tapes when the expiration date rolls 'round? That way your tapes come back to you as Scratch, with no clean up work to do afterward. Sounds like a make work project. Paul -- Jeff Cleverley Unix Systems Administrator Avago Technologies 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611 [EMAIL PROTECTED] ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Status 96 media allocation issues
Why would you not set your retentions correctly (ie, set to expire when you want them to) then have Iron Mountain automatically return the tapes when the expiration date rolls 'round? That way your tapes come back to you as Scratch, with no clean up work to do afterward. Sounds like a make work project. Paul -- -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Cleverley Sent: March 17, 2008 5:47 AM To: veritas-bu@mailman.eng.auburn.edu Subject: [Veritas-bu] Status 96 media allocation issues Greetings, I saw a post similar to this problem in February, but didn't really see an answer posted. I'm hoping someone can help me out. This is a 5.1 master running NDMP backups. The standard media policy is that they protected the data permanently and then expired the media once the tapes came back from Iron Mountain. We usually run a script against a file that has all the media to be expired in it. Below are the some of the commands in the script that run. The $i is the tape label being read from the list. /usr/openv/netbackup/bin/admincmd/bpmedia -unfreeze -m $i /usr/openv/volmgr/bin/vmquery -deassignbyid $i 1 0 # backup pool echo y | /usr/openv/netbackup/bin/admincmd/bpexpdate -d 0 -m $1 /dev/null echo y | /usr/openv/netbackup/bin/admincmd/bpexpdate -deassignempty -m $i /dev/null This has all worked until a couple of weeks ago. We ran the script, it deassigned the tapes, they showed up in the available for use and listed as scratch. When the backup ran, it loaded every tape and then asked for another one until they were all gone. I've rebooted the server, stopped and restarted everything, scanned libraries, and even deleted the media using the vmdelete command and then adding them back in using the robot inventory and update. I don't know if something may have changed on this server since I don't work with it locally or directly. One thing I did notice is that it isn't showing a scratch pool. It is automatically putting tapes in the Netbackup pools which I assume is OK. Below is some information about a tape that was deleted and re-added. This came from the bptm on the master. 23:14:32.574 [21509] 2 bptm: INITIATING (VERBOSE = 1): -ev 3284L2 -unfreeze 23:14:32.574 [21509] 2 db_byid: search for media id 3284L2 23:14:32.575 [21509] 2 db_byid: 3284L2 found at offset 153 23:33:05.682 [21870] 2 vmdb_query_scratch_bypool2: server returned: 1 3284L2 -- 6 003284L2 8 0 rds43 00_000_TLD - 46 0 0 0 0 root root 1 NetBackup - 1205739035 1205739158 0 0 0 0 0 0 0 - 0 0 50 0 0 0 0 0 - 0 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0 0 0 0 0 - Added by Media Manager 23:33:05.682 [21870] 2 db_byid: search for media id 3284L2 23:33:05.683 [21870] 2 db_byid: 3284L2 found at offset 153 23:33:05.683 [21870] 2 select_media: media id 3284L2 just obtained from Media Manager is already in the media database, requesting a new one Any help explaning why I can't get rid of these media and add them back in would be appreciated. Thanks, Jeff -- Jeff Cleverley Unix Systems Administrator Avago Technologies 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611 [EMAIL PROTECTED] ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu La version française suit le texte anglais. This email may contain privileged and/or confidential information, and the Bank of Canada does not waive any related rights. Any distribution, use, or copying of this email or the information it contains by other than the intended recipient is unauthorized. If you received this email in error please delete it immediately from your system and notify the sender promptly by email that you have done so. Le présent courriel peut contenir de l'information privilégiée ou confidentielle. La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute diffusion, utilisation ou copie de ce courriel ou des renseignements qu'il contient par une personne autre que le ou les destinataires désignés est interdite. Si vous recevez ce courriel par erreur, veuillez le supprimer immédiatement et envoyer sans délai à l'expéditeur un message électronique pour l'aviser que vous avez éliminé de votre ordinateur toute copie du courriel reçu. ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Status 96 media allocation issues
Paul, As mentioned, I only inherited the environment :-) I was told that the reason this was being done was they wanted to have the tapes and sessions protected until they decided to explicitly unprotect them. I think it stemmed more from paranoia and lack of understanding from the business. It is a bit of a make work thing. Jeff Paul Keating wrote: Why would you not set your retentions correctly (ie, set to expire when you want them to) then have Iron Mountain automatically return the tapes when the expiration date rolls 'round? That way your tapes come back to you as Scratch, with no clean up work to do afterward. Sounds like a make work project. Paul -- Jeff Cleverley Unix Systems Administrator Avago Technologies 4380 Ziegler Road Fort Collins, Colorado 80525 970-288-4611 [EMAIL PROTECTED] ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
