RE: testing recovery
- From: Robert Freeman <robertgfreeman@xxxxxxxxx>
- To: brian.zelli@xxxxxxxxxxxxxxx, andrew.kerber@xxxxxxxxx, chris.stephens@xxxxxxx
- Date: Tue, 6 Sep 2011 14:11:06 -0700 (PDT)
While I agree that the use of restore validate is a good practice, I would
strongly disagree that it takes the place of actual restore testing. This is
true with respect to DR or non-DR.
I say this for several reasons:
You will discover potential infrastructure issues that exist that could impact
your ability to restore the database. For example, if you had to restore it to
a different set of hardware, can that hardware access the tape pool. If not,
how do you deal with that.
Another reason is experience and preparation for the DBA.
There are other perfectly valid reasons...
It sounds like cost is an issue here. If you are running on linux or win then
spinning up a 1tb sandbox should not be that cost prohibitive. This might also
be a use case for OVM.
With respect to management and addressing these kind of demands from
management, this is where a well crafted and approved backup and recovery
policy comes into play and costs are addressed.
During the policy vetting process, costs must be associated with policy
directives. This gives management an up-front look at the costs related to the
policy they are approving. Then the question of "do we spend the money" becomes
academic because they signed up for it. Don't want to spend the money, fine.
Remove the policy item, eliminate the cost and make management sign off on it.
With new requirements such as this one, you simply say, "no, it is not part of
our policy" and you build process around updating that policy to reflect the
new standard(s) and costs. So, your answer is policy based, and the solution is
not a quick and dirty race to implement the brainchild idea of management but
rather a repeatable process to define policy and standards and a way to modify
those standards that makes sense to the org.
My opinion... I know there are those who scoff at policy and the like, but when
used properly it can help avoid headaches and the demands of the random
executive who gets a new idea in his head. It is also a very useful CYA tool.
Cheers
Rf
On Tue Sep 6th, 2011 3:15 PM EDT Zelli, Brian wrote:
>Yes, my last job only required once a quarter restores to satisfy SOX. But we
>were able to drop in a sandbox, or new dev or something like that. Here we
>have minimal hardware and space,
>ciao,
>Brian
>
>________________________________
>From: Andrew Kerber [mailto:andrew.kerber@xxxxxxxxx]
>Sent: Tuesday, September 06, 2011 2:45 PM
>To: Chris.Stephens@xxxxxxx
>Cc: Zelli, Brian; oracle-l@xxxxxxxxxxxxx
>Subject: Re: testing recovery
>
>I dont have a specific schedule, but when I do a restore I make note of it,
>and since so far I have had at least one restore per quarter, I have met the
>management requirement.
>
>On Tue, Sep 6, 2011 at 1:37 PM, Stephens, Chris
><Chris.Stephens@xxxxxxx<mailto:Chris.Stephens@xxxxxxx>> wrote:
>If you don't actually want to restore your database or clone it to a previous
>point in time to a different server, RMAN validate backup + restore preview
>functionality might satisfy management's requests.
>
>
>Chris
>
>
>-----Original Message-----
>From: oracle-l-bounce@xxxxxxxxxxxxx<mailto:oracle-l-bounce@xxxxxxxxxxxxx>
>[mailto:oracle-l-bounce@xxxxxxxxxxxxx<mailto:oracle-l-bounce@xxxxxxxxxxxxx>]
>On Behalf Of Zelli, Brian
>Sent: Tuesday, September 06, 2011 1:23 PM
>To: 'oracle-l@xxxxxxxxxxxxx<mailto:oracle-l@xxxxxxxxxxxxx>'
>Subject: testing recovery
>
>Ok, we just got hit with a "Are you testing your backups?" from senior
>administration. We sometimes use copies to replace test or dev but they want
>a scheduled plan. The first thing I mentioned was do you have enough
>space(some db's are over a 1T)? Do you have matching hardware sitting around
>that I can drop my db's onto? Licensing $$$$? What do you as a community do
>to satisfy or comply with this?
>ciao,
>Brian
>
>
>
>This email message may contain legally privileged and/or confidential
>information. If you are not the intended recipient(s), or the employee or
>agent responsible for the delivery of this message to the intended
>recipient(s), you are hereby notified that any disclosure, copying,
>distribution, or use of this email message is prohibited. If you have
>received this message in error, please notify the sender immediately by e-mail
>and delete this email message from your computer. Thank you.
>--
>//www.freelists.org/webpage/oracle-l
>
>
>
>CONFIDENTIALITY NOTICE:
> This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is privileged,
> confidential and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient or the employee or agent
> responsible for delivering this message to the intended recipient, you are
> hereby notified that any dissemination, distribution or copying of this
> communication is strictly prohibited. If you have received this
> communication in error, please notify us immediately by email reply.
>
>
>--
>//www.freelists.org/webpage/oracle-l
>
>
>
>
>
>--
>Andrew W. Kerber
>
>'If at first you dont succeed, dont take up skydiving.'
>
>
>This email message may contain legally privileged and/or confidential
>information. If you are not the intended recipient(s), or the employee or
>agent responsible for the delivery of this message to the intended
>recipient(s), you are hereby notified that any disclosure, copying,
>distribution, or use of this email message is prohibited. If you have
>received this message in error, please notify the sender immediately by e-mail
>and delete this email message from your computer. Thank you.
>--
>//www.freelists.org/webpage/oracle-l
>
>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
