Hi
I am TSM guy and recently assigned NBU project for writing scripts. Does
any body has sample scripts which i can learn ?
THX
On Mon, 17 Mar 2008 12:00:06 -0500,
veritas-bu-request AT mailman.eng.auburn DOT edu said:
> Send Veritas-bu mailing list submissions to
> veritas-bu AT mailman.eng.auburn DOT edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
> or, via email, send a message with subject or body 'help' to
> veritas-bu-request AT mailman.eng.auburn DOT edu
>
> You can reach the person managing the list at
> veritas-bu-owner AT mailman.eng.auburn DOT edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Veritas-bu digest..."
>
>
> Today's Topics:
>
> 1. Status 96 media allocation issues (Jeff Cleverley)
> 2. Re: Lets hear about your upgrade experience! 5.x - 6.5
> (Johan Redelinghuys)
> 3. Re: Status 96 media allocation issues (Paul Keating)
> 4. Netbackup 6.0 MP6 for Linux (Stumpr)
> 5. Re: Status 96 media allocation issues (Jeff Cleverley)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 17 Mar 2008 03:46:36 -0600
> From: Jeff Cleverley <jeff.cleverley AT avagotech DOT com>
> Subject: [Veritas-bu] Status 96 media allocation issues
> To: veritas-bu AT mailman.eng.auburn DOT edu
> Message-ID: <47DE3DFC.9000803 AT avagotech DOT com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> 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
> jeff.cleverley AT avagotech DOT com
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 17 Mar 2008 13:38:46 +0200
> From: "Johan Redelinghuys" <johan.redelinghuys AT stg.co DOT za>
> Subject: Re: [Veritas-bu] Lets hear about your upgrade experience! 5.x
> - 6.5
> To: "Jeff Lightner" <jlightner AT water DOT com>
> Cc: veritas-bu-bounces AT mailman.eng.auburn DOT edu,
> veritas-bu AT mailman.eng.auburn DOT edu
> Message-ID: <66A598DA26EF1043BA3B4E8A12108FAA01C57565@exchange>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi
>
>
>
> Good thing you are holding off with the upgrade because of Data Domain.
> We did the upgrade and everthing worked ok except Data Domain backups. To
> make a long story short, the problem was on the Data Domain side and it
> all had to do with permissions - This is was fixed it for us, so let the
> Data Domain Guys confirm:
>
>
>
> This can be resolved by logging into the ddr and running the following
> CIFS commands as well as changing some services for NBU on the windows
> system running NBU.
>
>
>
> On the DDR's command line run these commands:
>
>
>
> cifs option set guestaccount sysadmin
>
> cifs option set guestok yes
>
> cifs disable
>
> cifs enable
>
>
>
> On the Windows system running NBU change these services to be run as the
> user doing the backups.
>
>
>
> Netbackup Remote Manager and Monitor Service
>
> Netbackup Client Service
>
> Symantec Private Branch Exchange
>
>
>
> Hope this helps another person upgrading with Data Domain in the
> environment.
>
>
>
> JR
>
>
>
> From: veritas-bu-bounces AT mailman.eng.auburn DOT edu
> [mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of Jeff
> Lightner
> Sent: Thursday, March 13, 2008 3:28 PM
> To: Paul Keating; WEAVER, Simon (external); Ed Wilts
> Cc: veritas-bu AT mailman.eng.auburn DOT edu
> Subject: Re: [Veritas-bu] Lets hear about your upgrade experience! 5.x -
> 6.5
>
>
>
> On the flip side - at this point Symantec probably has more experience in
> migrating 5.1 to 6.0 than 6.5. Not having used 6.5 I can't say what, if
> any, differences there might be in doing such an upgrade. Many are
> saying 6.5 is just a "fix" of 6.0 but I imagine there ARE some
> differences. I do know that following the advice on this list we were
> able to go to 6.0 without suffering a lot after the conversion. We did
> have to do an iterative process in running the utility to check, have
> Symantec analyze it, then run it again and have another analysis done
> etc... until we got a run that had nothing left to be corrected and it
> was only at that point we did the upgrade.
>
>
>
> We're holding off on 6.5 mainly because we recently implemented Data
> Domain and want to make sure we understand how that impacts us coming on
> the heels of the 6.0 upgrade (which we waited for until MP4). Those who
> opted to wait for 6.5 to upgrade now seem to be feeling the pain of that
> decision which I counseled against on this list back when that thread
> occurred.
>
>
>
> ________________________________
>
> From: Paul Keating [mailto:pkeating AT bank-banque-canada DOT ca]
> Sent: Thursday, March 13, 2008 8:34 AM
> To: WEAVER, Simon (external); Ed Wilts
> Cc: veritas-bu AT mailman.eng.auburn DOT edu; Jeff Lightner
> Subject: RE: [Veritas-bu] Lets hear about your upgrade experience! 5.x -
> 6.5
>
>
>
> I think what Ed is saying is that either way (6.0 or 6.5) you have to
> make the transition from the old flat file binary catalog to the new
> sybase/EMM.
>
>
>
> Therefore, 5.x -> 6.0 or 5.x -> 6.5 is no difference.
>
>
>
> What you're saying about an easier transition to 6.5 I believe is merely
> symantec providing the means to go direct to 6.5 rather than make an
> intermediate step at 6.0, where no one likely wants to stay.
>
>
>
> Paul
>
>
>
>
>
> --
>
> -----Original Message-----
> From: veritas-bu-bounces AT mailman.eng.auburn DOT edu
> [mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of
> WEAVER, Simon (external)
> Sent: March 13, 2008 3:50 AM
> To: Ed Wilts
> Cc: veritas-bu AT mailman.eng.auburn DOT edu; Jeff Lightner
> Subject: Re: [Veritas-bu] Lets hear about your upgrade experience! 5.x
> - 6.5
>
> Hello Ed
>
> I am basing this comment (as you detailed below) on a discussion with
> Symantec. that is not to say its right, but I know after the huge cock-ups
> there were with 6.x one of their focus points was an easier transition from
> 5.x to 6.5 or 6.5.1
>
>
>
> Of course, alot would depend on the environment, and also the stability
> of that environment. I guess one small fault can cause an endless amount of
> headaches and quite possible downtime for your NetBackup environment.
>
>
>
> Having Symantec on the end of the phone could be a good thing....
> depending on their expertise me thinks.
>
>
>
> In regards to the second comment (see below in blue), I did respond to
> this in another thread of the same subject line.
>
> Hopefully this is clear.
>
>
>
> Thanks, Simon
>
>
>
> ________________________________
>
> From: Ed Wilts [mailto:ewilts AT ewilts DOT org]
> Sent: Wednesday, March 12, 2008 4:56 PM
> To: WEAVER, Simon (external)
> Cc: Jeff Lightner; Tony T.; veritas-bu AT mailman.eng.auburn DOT edu
> Subject: Re: [Veritas-bu] Lets hear about your upgrade experience! 5.x
> - 6.5
>
> On Wed, Mar 12, 2008 at 10:33 AM, WEAVER, Simon (external)
> <simon.weaver AT astrium.eads DOT net> wrote:
>
> > it seems that going from 5.1 to 6.5 or even 6.5.1 should be the
> easier upgrade path.
>
>
> What are you basing this on? The 6.0 to 6.5 upgrade has been
> relatively painless for everybody. It's always been the 5.x to 6.0 upgrade
> that has been the issue and the steps to do that are in the 5.1 to 6.5 path -
> you can't avoid the migration by skipping 6.0.
>
> In general, the uglier the source environment in 5.1, the uglier the
> migration, and it hasn't always been the admin's fault (although sometimes it
> has been). Some things worked in earlier releases but were never really
> documented or supported and NetBackup is not unique in this. The more
> complex the product is, the uglier upgrades are going to be since there are
> too many input permutations to even consider testing. There are lots of
> environments out there where Symantec just says "we didn't know anybody was
> even doing *that*" or "we didn't even know you *could* do that".
>
> If the source environment would have been bugfree since it was
> installed, it would be easier, but it wasn't - all releases that I've worked
> on, going back to 3.4 had some set of bugs that would leave the system in
> weird and wonderful states. That makes the upgrade even harder since they
> can't just trust that the source system was pristine. It also doesn't help
> that sometimes the upgrade processes themselves have bugs.
>
>
> > maybe careful planning is the key?
>
> Careful planning is always key but this alone doesn't guarantee a
> successful outcome. Part of the planning, however, should include a fall
> back plan...
>
> .../Ed
> --
> Ed Wilts, Mounds View, MN, USA
> mailto:ewilts AT ewilts DOT org
>
> 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
>
> ====================================================================================
>
> 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.
>
> ----------------------------------
> CONFIDENTIALITY NOTICE: This e-mail may contain privileged or
> confidential information and is for the sole use of the intended
> recipient(s). If you are not the intended recipient, any disclosure,
> copying, distribution, or use of the contents of this information is
> prohibited and may be unlawful. If you have received this electronic
> transmission in error, please reply immediately to the sender that you
> have received the message in error, and delete it. Thank you.
> ----------------------------------
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://mailman.eng.auburn.edu/pipermail/veritas-bu/attachments/20080317/62c94397/attachment-0001.html
>
> ------------------------------
>
> Message: 3
> Date: Mon, 17 Mar 2008 09:48:36 -0400
> From: "Paul Keating" <pkeating AT bank-banque-canada DOT ca>
> Subject: Re: [Veritas-bu] Status 96 media allocation issues
> To: "Jeff Cleverley" <jeff.cleverley AT avagotech DOT com>,
> <veritas-bu AT mailman.eng.auburn DOT edu>
> Message-ID:
> <D97555B4BDFFFD46B0F3BEB46C29D2AC68A244 AT
> EXMAIL1.bocad.bank-banque-canada DOT ca>
>
> Content-Type: text/plain; charset="utf-8"
>
> 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: veritas-bu-bounces AT mailman.eng.auburn DOT edu
> > [mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf
> > Of Jeff Cleverley
> > Sent: March 17, 2008 5:47 AM
> > To: veritas-bu AT mailman.eng.auburn DOT 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
> > jeff.cleverley AT avagotech DOT com
> >
> >
> > _______________________________________________
> > Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT 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.
>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 17 Mar 2008 10:33:54 -0400
> From: Stumpr <netbackup-forum AT backupcentral DOT com>
> Subject: [Veritas-bu] Netbackup 6.0 MP6 for Linux
> To: VERITAS-BU AT mailman.eng.auburn DOT edu
> Message-ID: <1205764434.m2f.267742 AT www.backupcentral DOT com>
>
>
> Thanks Ed
>
> +----------------------------------------------------------------------
> |This was sent by bob.stump AT fnis DOT com via Backup Central.
> |Forward SPAM to abuse AT backupcentral DOT com.
> +----------------------------------------------------------------------
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 17 Mar 2008 09:07:30 -0600
> From: Jeff Cleverley <jeff.cleverley AT avagotech DOT com>
> Subject: Re: [Veritas-bu] Status 96 media allocation issues
> To: Paul Keating <pkeating AT bank-banque-canada DOT ca>
> Cc: veritas-bu AT mailman.eng.auburn DOT edu
> Message-ID: <47DE8932.1090109 AT avagotech DOT com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> 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
> jeff.cleverley AT avagotech DOT com
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
>
>
> End of Veritas-bu Digest, Vol 23, Issue 33
> ******************************************
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
