Not to be obstructive but this is a huge answer.
Is there something specific you're looking to do?
Otherwise, I suggest you curl up with the command-line reference
guide... and a lot of coffee. Everything about scripting netbackup is
based on those commands.
Welcome to the dark side - it's OK - we have cookies!
-M
-----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
ANIL555 AT MAURYA DOT US
Sent: Monday, March 17, 2008 11:57 AM
To: veritas-bu AT mailman.eng.auburn DOT edu
Subject: [Veritas-bu] Netbackup sample scripts
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 DOT bank-banque-canada
.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
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
