Re: Lightweight method for testing database backup processes

"A DBA is only as good as their last backup."

Your welcome!

On Mon, Aug 21, 2017 at 8:06 AM Chris Stephens <cstephens16_at_gmail.com> wrote:

> i implicitly test my car every morning to get to work. i guess it would
> no longer be a daily test if i lost my job because my database wasn't
> recoverable. i get your point though.
>
> thanks for the link Kellyn!
>
>
> On Mon, Aug 21, 2017 at 8:55 AM Mladen Gogala <gogala.mladen_at_gmail.com>
> wrote:
>
>> Why would you want to rest rman backups? Do you have any doubts of their
>> quality? You can do "restore validate" is you suspect a problem. I
>> understand that you should be cautious, but rman has proven itself many
>> times over, there is no need to test it whether it will work. Do you test
>> your car every morning?
>>
>> On 08/21/2017 09:39 AM, Chris Stephens wrote:
>>
>> We are looking for an efficient way to regularly test RMAN backups across
>> a large (and growing) Exadata database environment.
>>
>> After watching this video https://youtu.be/Ds1xrfdlZRc i thought about
>> doing the following:
>>
>> create a dedicated, small tablespace in all databases to hold a single
>> table with a single date/timestamp column. create a scheduler job to
>> insert current sysdate/systimestamp value once per day and delete all rows
>> older than recovery window setting for RMAN.
>>
>> write a script to 1) randomly pick a database on each Exadata system 2)
>> randomly pick a day that falls within the recovery window requirement for
>> that database 3) converts that day to a valid SCN 4) uses the new table
>> PITR functionality to restore the table 4) confirm expected table content
>> 5) sends success/failure summary email.
>>
>> execute the script with a frequency that makes us feel comfortable with
>> our backups.
>>
>> we also intend to have a process that utilizes the "restore preview" RMAN
>> command to get a list of backup pieces to run the RMAN "validate" command
>> against for a randomly chosen SCN that falls within recovery window.
>>
>> Does anyone see any big issues with this process? Any other ideas for
>> efficiently testing database backups? our databases will soon be large
>> enough to make testing through full restores infeasible.
>>
>> any feedback is greatly appreciated!
>>
>> thanks,
>> chris
>>
>>
>> --
>> Mladen Gogala
>> Oracle DBA
>> Tel: (347) 321-1217
>>
>> --

[image: Kellyn Pot'Vin on about.me]

Kellyn Pot'Vin-Gorman
about.me/dbakevlar
  <http://about.me/dbakevlar>

--
http://www.freelists.org/webpage/oracle-l