Re: Lightweight method for testing database backup processes

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
>
>

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