Re: Lightweight method for testing database backup processes

For several centuries, people have used a technique called "testing" to proactively verify that complex processes and procedures actually perform as intended.

While many remain content to rely on faith or theory, skeptics find comfort in such validation, even when the effort seems wasted due to repeated success. As with cranks through the ages, people who "test" contend (among other things, for example) that something underlying might change. Although vexing to the faithful, testing brings a curious sense of tranquillity to the skeptic.

And although the OP did politely state "any feedback is greatly appreciated", it may save effort and time to assume that the decision to perform such "testing" has already been made, and consider basing future feedback forward from that point?

On 8/21/17 07:53, Mladen Gogala 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

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