Veritas-bu

[Veritas-bu] Recovery of Production data onto Test hardware

2002-04-24 15:10:51
Subject: [Veritas-bu] Recovery of Production data onto Test hardware
From: Mark.Donaldson AT experianems DOT com (Donaldson, Mark)
Date: Wed, 24 Apr 2002 13:10:51 -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_01C1EBC3.C02980A0
Content-Type: text/plain;
        charset="iso-8859-1"

Part of this is going to depend on your subnet arrangement.  Your backup
server scenario is going to work easier if they're on the same network
subnet.  Your note implies that's the case so I'll work with that.

Things to do ahead of time:
1. Install all your oracle binaries on Test server - if you use a different
version of Oracle on test than production - install both.  This saves all
the library issues.
2. Sync the OS versions on test & prod

Things you're going to restore from prod to test:
1. Data files & control files (OFA structure):
/uXX/oradata/<instance>/*.dbf, /u01/app/oracle/admin/<instance>
2. Enough archived redo to roll the instance to current time (or nearly so)
3. /var/spool/cron/crontabs/oracle

If your production system is on the same subnet as your test system, you
should be able to bring the production IP address up on the same interface
as your test address as an alias.  Now you don't have to make tnsnames
changes to the clients.  Don't try to recover the OS from production -
you'll struggle getting it right.  Make a clean distinction between, OS,
application, and data and you can treat this like a clustered or HA system.
If you can get the data on some sort of shared storage system, then you can
move the data using Veritas volume groups; just deport on the undesired
system and import on demand.

Drop me a line if you have questions. This note is deliberately short...

-Mark

-----Original Message-----
From: William Enestvedt [mailto:Will.Enestvedt AT jwu DOT edu]
Sent: Wednesday, April 24, 2002 11:54 AM
To: veritas-bu AT mailman.eng.auburn DOT edu
Subject: [Veritas-bu] Recovery of Production data onto Test hardware


Can someone help my better understand the whole disaster-recovery process
for my Sun Oracle servers (E3500's and E420R's)?
   I have two sets of identical hardware, Production (which actual users
access) and Test (where my Oracle dba's and developers try out their code),
which comprise a database server and an application server. In the event of
some catastrophe on the Production hardware, I want to be able to recover
the most recent backup of Production onto the Test hardware and bring that
up in its place until I can get the full-time kit repaired. (Specs: Solaris
2.6, E3500 for database servers, E420R for application servers, NBU Data
Center 3.4.)
   I have two questions here: which files on Test are required to be changed
in order for it to advertise itself as the Production system without a full
reinstall-and-recovery -- i.e., IP address, hostname, and/or port numbers?
-- and which files need to be restored in order to have the full
functionality of the database on the Test hardware -- i.e. all the stuff in
the /vol1/oradata/ directories, and/or Something else?
   I tried this last week, and the Test system wouldn't boot. (Presumably, I
accidentally restored some production OS files I didn't need in the, um,
/kernel directory or something. Ooops!) I Jumpstarted it and then restored
the data and the relevant /etc/files, but now I'm spooked about my "disaster
recovery plans" (which are turning out to be sketchier, and more naive, than
I'd thought).
   If I change the Test system's hostname from (let's just pretend here)
oracle_test.college.edu to oracle_production.college.edu and change to the
corresponding IP address, will that be enough?
   I see the 31 steps and gajillion arrows in the eye-exploding flowchart on
p.484 of Curtis Preston's "Unix Backup & Recovery" which tell me how to
hot-recover an Oracle database, but I'm hoping to avoid those with a
wholesale NBU restore of the "cold" database -- but I'm still up against the
question of doing it onto a different host. Would doing a complete restore
of the root Production filesystem onto one of Test's redundant boot disks be
enough?
   Thanks for any help. This undoubtedly sounds a little ignorant, but it's
one of those days where I figure I oughtta to shine a light under the
kitchen cabinets no matter how dumb I look.
-wde
P.S. Does anyone have a bootable CD with the NBU client on it that they use
for recoveries? Or is there an
--
Will Enestvedt
UNIX System Administrator
Johnson & Wales University -- Providence, RI
_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

------_=_NextPart_001_01C1EBC3.C02980A0
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] Recovery of Production data onto Test =
hardware</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Part of this is going to depend on your subnet =
arrangement.&nbsp; Your backup server scenario is going to work easier =
if they're on the same network subnet.&nbsp; Your note implies that's =
the case so I'll work with that.</FONT></P>

<P><FONT SIZE=3D2>Things to do ahead of time:</FONT>
<BR><FONT SIZE=3D2>1. Install all your oracle binaries on Test server - =
if you use a different version of Oracle on test than production - =
install both.&nbsp; This saves all the library issues.</FONT></P>

<P><FONT SIZE=3D2>2. Sync the OS versions on test &amp; prod</FONT>
</P>

<P><FONT SIZE=3D2>Things you're going to restore from prod to =
test:</FONT>
<BR><FONT SIZE=3D2>1. Data files &amp; control files (OFA structure): =
/uXX/oradata/&lt;instance&gt;/*.dbf, =
/u01/app/oracle/admin/&lt;instance&gt;</FONT>
<BR><FONT SIZE=3D2>2. Enough archived redo to roll the instance to =
current time (or nearly so)</FONT>
<BR><FONT SIZE=3D2>3. /var/spool/cron/crontabs/oracle</FONT>
</P>

<P><FONT SIZE=3D2>If your production system is on the same subnet as =
your test system, you should be able to bring the production IP address =
up on the same interface as your test address as an alias.&nbsp; Now =
you don't have to make tnsnames changes to the clients.&nbsp; Don't try =
to recover the OS from production - you'll struggle getting it =
right.&nbsp; Make a clean distinction between, OS, application, and =
data and you can treat this like a clustered or HA system.&nbsp; If you =
can get the data on some sort of shared storage system, then you can =
move the data using Veritas volume groups; just deport on the undesired =
system and import on demand.</FONT></P>

<P><FONT SIZE=3D2>Drop me a line if you have questions. This note is =
deliberately short...</FONT>
</P>

<P><FONT SIZE=3D2>-Mark</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: William Enestvedt [<A =
HREF=3D"mailto:Will.Enestvedt AT jwu DOT edu">mailto:Will.Enestvedt AT jwu DOT 
edu</A>=
]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, April 24, 2002 11:54 AM</FONT>
<BR><FONT SIZE=3D2>To: veritas-bu AT mailman.eng.auburn DOT edu</FONT>
<BR><FONT SIZE=3D2>Subject: [Veritas-bu] Recovery of Production data =
onto Test hardware</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Can someone help my better understand the whole =
disaster-recovery process</FONT>
<BR><FONT SIZE=3D2>for my Sun Oracle servers (E3500's and =
E420R's)?</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; I have two sets of identical hardware, =
Production (which actual users</FONT>
<BR><FONT SIZE=3D2>access) and Test (where my Oracle dba's and =
developers try out their code),</FONT>
<BR><FONT SIZE=3D2>which comprise a database server and an application =
server. In the event of</FONT>
<BR><FONT SIZE=3D2>some catastrophe on the Production hardware, I want =
to be able to recover</FONT>
<BR><FONT SIZE=3D2>the most recent backup of Production onto the Test =
hardware and bring that</FONT>
<BR><FONT SIZE=3D2>up in its place until I can get the full-time kit =
repaired. (Specs: Solaris</FONT>
<BR><FONT SIZE=3D2>2.6, E3500 for database servers, E420R for =
application servers, NBU Data</FONT>
<BR><FONT SIZE=3D2>Center 3.4.)</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; I have two questions here: which files =
on Test are required to be changed</FONT>
<BR><FONT SIZE=3D2>in order for it to advertise itself as the =
Production system without a full</FONT>
<BR><FONT SIZE=3D2>reinstall-and-recovery -- i.e., IP address, =
hostname, and/or port numbers?</FONT>
<BR><FONT SIZE=3D2>-- and which files need to be restored in order to =
have the full</FONT>
<BR><FONT SIZE=3D2>functionality of the database on the Test hardware =
-- i.e. all the stuff in</FONT>
<BR><FONT SIZE=3D2>the /vol1/oradata/ directories, and/or Something =
else?</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; I tried this last week, and the Test =
system wouldn't boot. (Presumably, I</FONT>
<BR><FONT SIZE=3D2>accidentally restored some production OS files I =
didn't need in the, um,</FONT>
<BR><FONT SIZE=3D2>/kernel directory or something. Ooops!) I =
Jumpstarted it and then restored</FONT>
<BR><FONT SIZE=3D2>the data and the relevant /etc/files, but now I'm =
spooked about my &quot;disaster</FONT>
<BR><FONT SIZE=3D2>recovery plans&quot; (which are turning out to be =
sketchier, and more naive, than</FONT>
<BR><FONT SIZE=3D2>I'd thought).</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; If I change the Test system's hostname =
from (let's just pretend here)</FONT>
<BR><FONT SIZE=3D2>oracle_test.college.edu to =
oracle_production.college.edu and change to the</FONT>
<BR><FONT SIZE=3D2>corresponding IP address, will that be =
enough?</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; I see the 31 steps and gajillion arrows =
in the eye-exploding flowchart on</FONT>
<BR><FONT SIZE=3D2>p.484 of Curtis Preston's &quot;Unix Backup &amp; =
Recovery&quot; which tell me how to</FONT>
<BR><FONT SIZE=3D2>hot-recover an Oracle database, but I'm hoping to =
avoid those with a</FONT>
<BR><FONT SIZE=3D2>wholesale NBU restore of the &quot;cold&quot; =
database -- but I'm still up against the</FONT>
<BR><FONT SIZE=3D2>question of doing it onto a different host. Would =
doing a complete restore</FONT>
<BR><FONT SIZE=3D2>of the root Production filesystem onto one of Test's =
redundant boot disks be</FONT>
<BR><FONT SIZE=3D2>enough?</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; Thanks for any help. This undoubtedly =
sounds a little ignorant, but it's</FONT>
<BR><FONT SIZE=3D2>one of those days where I figure I oughtta to shine =
a light under the</FONT>
<BR><FONT SIZE=3D2>kitchen cabinets no matter how dumb I look.</FONT>
<BR><FONT SIZE=3D2>-wde</FONT>
<BR><FONT SIZE=3D2>P.S. Does anyone have a bootable CD with the NBU =
client on it that they use</FONT>
<BR><FONT SIZE=3D2>for recoveries? Or is there an</FONT>
<BR><FONT SIZE=3D2>--</FONT>
<BR><FONT SIZE=3D2>Will Enestvedt</FONT>
<BR><FONT SIZE=3D2>UNIX System Administrator</FONT>
<BR><FONT SIZE=3D2>Johnson &amp; Wales University -- Providence, =
RI</FONT>
<BR><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>Veritas-bu maillist&nbsp; -&nbsp; =
Veritas-bu AT mailman.eng.auburn DOT edu</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu"; =
TARGET=3D"_blank">http://mailman.eng.auburn.edu/mailman/listinfo/veritas=
-bu</A></FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1EBC3.C02980A0--

<Prev in Thread] Current Thread [Next in Thread>