Re: Lightweight method for testing database backup processes

From: Kellyn Pot'Vin-Gorman <dbakevlar_at_gmail.com>
Date: Mon, 21 Aug 2017 16:56:51 +0300
Message-ID: <1503323810.733426332_at_f29.my.com>



Apologies-  I'm not sure if y'all are just hitting on topics that all fall into virtualization, but this is one of the key points of Delphix and other solutions that utilize the native backup technology.  When you use virtualized environments, like ours, then you're using an RMAN recovery check each time you create a virtualized database, (vdb), which offers a number of secondary solutions, including that check of your backup.  

Exadata has sparse Clone copy capability, thin clone via EM, snap clone and others, which is similar and I'd recommend looking into the potential of using that to verify your backups when you create the test master.  Oracle's documentation spread out, (considering how many different and varying levels of products/costs). Since you have exadata, I'm going with this doc-  http://docs.oracle.com/cd/E80920_01/SAGUG/exadata-storage-server-snapshots.htm#SAGUG20386

This will eliminate the complexity and storage demands with your current scenario, along with a template that is easily repeatable.

Kellyn

Sent from myMail for iOS

Monday, August 21, 2017, 7:39 AM -0600 from Chris Stephens <cstephens16_at_gmail.com>:
>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

--
http://www.freelists.org/webpage/oracle-l
Received on Mon Aug 21 2017 - 15:56:51 CEST

Original text of this message