Re: RMAN backup validate

From: MARK BRINSMEAD <mark.brinsmead_at_gmail.com>
Date: Sun, 15 Mar 2015 00:13:01 -0400
Message-ID: <CAAaXtLAStFweGK3E+x1D8xKefLx0ibbT5h4Wg4UiZrzABzvUmA_at_mail.gmail.com>



Hmmm.

"SAN Snapshots". These are *great*, when used properly. And I am sure that Mladen does.

These things scare me some, though, because some people don't seem to understand that some (most?) SAN snapshots -- the ones that are described as "near instantaneous" -- aren't REALLY "backups" until you COPY the data to another volume. (And if you have a "smart" SAN array with de-dupe technology, that may mean copying to an entirely different array.)

If you don't make a copy (and ensure it is not "de-duped") then there is a good chance that your "snapshot" is still dependent on the physical integrity of the original data/storage. Lose the disks holding the original data, and you lose the snapshot, too. This is not always going to be the case, of course (every vendor's offering is different), but it will probably be the case a lot of the time.

Just something to remember when we say "snapshot" and "backup" in the same sentence. ;-)

On Sat, Mar 14, 2015 at 11:23 PM, Mladen Gogala <dmarc-noreply_at_freelists.org
> wrote:

> On 03/14/2015 07:36 PM, Hans Forbrich wrote:
>
>> On 14/03/2015 1:53 PM, Andrew Kerber wrote:
>>
>>> You should also do a full restore periodically to verify the validity of
>>> your recovery plan. At least every 6 months.
>>>
>>>
>> In paper, I agree ...
>>
>> As long as we have identified a recovery plan, and possibly even have
>> have distinguished between HA and DR - which some do, and some don't - it
>> is a great idea to test whether the recovery plan actually works and
>> whether people involved in implementing it actually can do so.
>>
>> I do note that some organizations have a variety of recovery ideas, and
>> sometimes even formal plans, for a variety of situationsing ; tier 1 might
>> involve RAC, tier 2 might involve local Standby even Active DG, tier 3
>> might involve offsite DR practices.
>>
>> I also note that the recovery plan can not be limited to the database
>> piece. Too many apps have hard-coded stuff, such as database server names
>> or IP addresses. Testing the recovery plan must involve more than just
>> checking whether we can restore the database.
>>
>> I finally note that good DR readiness is blinking expensive, is based on
>> analysis that few actually do, is generally Pi in the sky, and is rarely
>> really supported by management other than "of course we need it". It would
>> be interesting to create a Jeremy poll to find out how many actually do
>> perform end-to-end recovery plan testing.
>>
>> /Hans
>> happy Pi day everyone
>>
>>
>> --
>> http://www.freelists.org/webpage/oracle-l
>>
>>
>> Hans, I agree with you completely. However, I would like to add things
> like SAN snapshots and "merge backup" strategies (incremental recovery of a
> copy in FRA), which can further make the disaster recovery quicker and more
> effective. What you have listed (RAC, local standby, remote standby and
> backup) are traditional means of recovery. Merge backups and SAN snapshots
> are relative novelties which can really speed things up.
>
>
> --
> Mladen Gogala
> Oracle DBA
> http://mgogala.freehostia.com
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Sun Mar 15 2015 - 05:13:01 CET

Original text of this message