Veritas-bu

[Veritas-bu] NBU 4.5 backing up databases, but this applies t o 3.4 as well

2002-10-23 11:09:48
Subject: [Veritas-bu] NBU 4.5 backing up databases, but this applies t o 3.4 as well
From: Mark.Donaldson AT experianems DOT com (Donaldson, Mark)
Date: Wed, 23 Oct 2002 09:09:48 -0600
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C27AA6.3AAFE140
Content-Type: text/plain;
        charset="iso-8859-1"

An option is use one Policy/class but multiple schedules.

I have one backup preparation script with lots of sym-links to it (related
to schedule name) for my big cluster set of five DB instances, ie:
 
backup_prep <- bpstart_notify.dbclass.sidname1
backup_prep <- bpstart_notify.dbclass.sidname2

The schedule name is a passed parameter to the dbstart_notify script.  Name
the schedule the same as your sidname and you've got one script that does it
all.

The downside, of course, is the clientlist.  You'll need one policy for
every host and one (or more) schedule for each instance on that host.  Name
the class something related to the hostname and you could parse that too.

for the transaction logs, use a cron job on the client and the bpbackup or
bparchive tool to do a user-directed backup (or archive) to tape.  Have them
all point to the same policy with various schedules for the variety of
retentions, etc. that'll probably be wanted.

This method might work for the export backups, too.  Since they're allready
driving the export via some sort of scheduler on the client, have them
complete the process by backing up their own set of files, on their
schedule, to a user-directed backup or archive class.

HTH  -Mark


-----Original Message-----
From: briandiven AT northwesternmutual DOT com
[mailto:briandiven AT northwesternmutual DOT com]
Sent: Wednesday, October 23, 2002 8:44 AM
To: veritas-bu AT mailman.eng.auburn DOT edu
Subject: [Veritas-bu] NBU 4.5 backing up databases, but this applies to
3.4 as well


The NBU policies allow me to call scripts, however I can't pass
parameters which would at least allow me to use a single script. Having
multiple databases per server - the first conclusion is that I would
need 1,000 policies and 1,000 scripts to backup 1,000 DB's. Am I missing
something obvious here? 


The plot thickens in that the various database teams desire unique
schedules. So maybe I could have NBU call a master script which reads a
list of backup parameters and feeds those to an actual backup script.
But with the various schedules, that could mean more interrogation about
each day of the week. Pretty soon I'm writing my own scheduling
software. 


It gets deeper when I find that the desire is to dump the transaction
logs hourly for some DB's during the week. Without going deeper, that
could mean 1,000 jobs get submitted hourly of which only some would
actually submit a backup. 


This is all "very NOT good." Our databases are mostly on raw partitions,
so the current structure is to export to a /opt/openv/backup directory,
back this up, and then clean it up using 1 script with parms being
passed using CAM (a backup product from StorageTek that will drop
support at the end of the year). I'm struggling finding a best practice
under NBU so would appreciate ANY and ALL ideas to siphon into my tank
of ideas. 


We are primarily a Sybase shop with some Oracle and expanding with DB2.




Brian Diven
Enterprise Storage Management
Northwestern Mutual
(414) 665-6123


------_=_NextPart_001_01C27AA6.3AAFE140
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [Veritas-bu] NBU 4.5 backing up databases, but this applies =
to 3.4 as well</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>An option is use one Policy/class but multiple =
schedules.</FONT>
</P>

<P><FONT SIZE=3D2>I have one backup preparation script with lots of =
sym-links to it (related to schedule name) for my big cluster set of =
five DB instances, ie:</FONT></P>

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>backup_prep &lt;- =
bpstart_notify.dbclass.sidname1</FONT>
<BR><FONT SIZE=3D2>backup_prep &lt;- =
bpstart_notify.dbclass.sidname2</FONT>
</P>

<P><FONT SIZE=3D2>The schedule name is a passed parameter to the =
dbstart_notify script.&nbsp; Name the schedule the same as your sidname =
and you've got one script that does it all.</FONT></P>

<P><FONT SIZE=3D2>The downside, of course, is the clientlist.&nbsp; =
You'll need one policy for every host and one (or more) schedule for =
each instance on that host.&nbsp; Name the class something related to =
the hostname and you could parse that too.</FONT></P>

<P><FONT SIZE=3D2>for the transaction logs, use a cron job on the =
client and the bpbackup or bparchive tool to do a user-directed backup =
(or archive) to tape.&nbsp; Have them all point to the same policy with =
various schedules for the variety of retentions, etc. that'll probably =
be wanted.</FONT></P>

<P><FONT SIZE=3D2>This method might work for the export backups, =
too.&nbsp; Since they're allready driving the export via some sort of =
scheduler on the client, have them complete the process by backing up =
their own set of files, on their schedule, to a user-directed backup or =
archive class.</FONT></P>

<P><FONT SIZE=3D2>HTH&nbsp; -Mark</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: briandiven AT northwesternmutual DOT com</FONT>
<BR><FONT SIZE=3D2>[<A =
HREF=3D"mailto:briandiven AT northwesternmutual DOT com">mailto:briandiven@nort=
hwesternmutual.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, October 23, 2002 8:44 AM</FONT>
<BR><FONT SIZE=3D2>To: veritas-bu AT mailman.eng.auburn DOT edu</FONT>
<BR><FONT SIZE=3D2>Subject: [Veritas-bu] NBU 4.5 backing up databases, =
but this applies to</FONT>
<BR><FONT SIZE=3D2>3.4 as well</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>The NBU policies allow me to call scripts, however I =
can't pass</FONT>
<BR><FONT SIZE=3D2>parameters which would at least allow me to use a =
single script. Having</FONT>
<BR><FONT SIZE=3D2>multiple databases per server - the first conclusion =
is that I would</FONT>
<BR><FONT SIZE=3D2>need 1,000 policies and 1,000 scripts to backup =
1,000 DB's. Am I missing</FONT>
<BR><FONT SIZE=3D2>something obvious here? </FONT>
</P>
<BR>

<P><FONT SIZE=3D2>The plot thickens in that the various database teams =
desire unique</FONT>
<BR><FONT SIZE=3D2>schedules. So maybe I could have NBU call a master =
script which reads a</FONT>
<BR><FONT SIZE=3D2>list of backup parameters and feeds those to an =
actual backup script.</FONT>
<BR><FONT SIZE=3D2>But with the various schedules, that could mean more =
interrogation about</FONT>
<BR><FONT SIZE=3D2>each day of the week. Pretty soon I'm writing my own =
scheduling</FONT>
<BR><FONT SIZE=3D2>software. </FONT>
</P>
<BR>

<P><FONT SIZE=3D2>It gets deeper when I find that the desire is to dump =
the transaction</FONT>
<BR><FONT SIZE=3D2>logs hourly for some DB's during the week. Without =
going deeper, that</FONT>
<BR><FONT SIZE=3D2>could mean 1,000 jobs get submitted hourly of which =
only some would</FONT>
<BR><FONT SIZE=3D2>actually submit a backup. </FONT>
</P>
<BR>

<P><FONT SIZE=3D2>This is all &quot;very NOT good.&quot; Our databases =
are mostly on raw partitions,</FONT>
<BR><FONT SIZE=3D2>so the current structure is to export to a =
/opt/openv/backup directory,</FONT>
<BR><FONT SIZE=3D2>back this up, and then clean it up using 1 script =
with parms being</FONT>
<BR><FONT SIZE=3D2>passed using CAM (a backup product from StorageTek =
that will drop</FONT>
<BR><FONT SIZE=3D2>support at the end of the year). I'm struggling =
finding a best practice</FONT>
<BR><FONT SIZE=3D2>under NBU so would appreciate ANY and ALL ideas to =
siphon into my tank</FONT>
<BR><FONT SIZE=3D2>of ideas. </FONT>
</P>
<BR>

<P><FONT SIZE=3D2>We are primarily a Sybase shop with some Oracle and =
expanding with DB2.</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>Brian Diven</FONT>
<BR><FONT SIZE=3D2>Enterprise Storage Management</FONT>
<BR><FONT SIZE=3D2>Northwestern Mutual</FONT>
<BR><FONT SIZE=3D2>(414) 665-6123</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C27AA6.3AAFE140--

<Prev in Thread] Current Thread [Next in Thread>
  • [Veritas-bu] NBU 4.5 backing up databases, but this applies t o 3.4 as well, Donaldson, Mark <=