Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Re: How to validate RMAN backup

Re: How to validate RMAN backup

From: Mark Brinsmead <pythianbrinsmead_at_gmail.com>
Date: Thu, 25 May 2006 21:21:49 -0600
Message-ID: <cf3341710605252021p61834ba8vc7236b06f8eab0c7@mail.gmail.com>


I don't think that's the kind of "faith" that Mladan was referring to. ;-)

Anyway, I for one maintain that there is one and only one way to prove that a backup works.
Restore it and open the database.

And to that end, DUPLICATE DATABASE is incredibly tough to beat.

Does VALIDATE BACKUP actually guarantee that you have all of the datafiles you need? Or just that the
datafiles included in the last backup? (Sadly, that particular question is not rhetorical; I've never bothered
to check.)

Does VALIDATE BACKUP assure you that you have all of the archived redo necessary? Or that your
files are actually on *tape*. (Lots of people these days seem to backup first to disk, then migrate
to tape.)

Does VALIDATE BACKUP assure you that the tapes are actually READABLE on your recovery
server and/or with the tape drives at your disaster recovery site? (I've seen things that can prevent
both.)

Does VALIDATE BACKUP guarantee that you have backups of your controlfiles, SPFILE, etc? (Well,
I guess it might, but I bet it doesn't.)

Does VALIDATE BACKUP actually make you (or your junior DBAs or operators) perform mock
recoveries, thus ensuring that your recovery procedures are A) well documented, and B) well
understood by those who will need to do them?

When it comes to backup and recovery, I think there is a lot of room for (healthy) skepticism. That
said, I was once asked to craft a test that would *proved* that Oracle's forward-recovery mechanism
would *really* (and correctly) recover a database to a point in time. The manager who asked for this
was not willing to accept the "word" of the Oracle database when *said* it had recovered correctly
to the required point-in-time. The test I was asked to design had to compare two databases record
by record, and prove that their (logical) contents were identical. Oddly, that test was never actually
performed... ;-)

Anyway, being a little bit old fashioned, and not liking to have claims made against my liability
insurance (I'm sure my underwriter will be happy to hear that) I will lean toward the DUPLICATE
DATABASE method. Every time.

Actually, my liability insurance *excludes* coverage for work relating to backup and recovery.
I wonder why? (*That* question *is* rhetorical!)

Anyway, I'm sure other opinions will undoubtedly abound. ;-)

On 5/25/06, Mercadante, Thomas F (LABOR) < Thomas.Mercadante_at_labor.state.ny.us> wrote:
>
> Amen Brother!!!!
>
> Praise Jeeeesuuuuuus!
>
>

-- 
Cheers,
-- Mark Brinsmead
   Staff DBA,
   The Pythian Group
   http://www.pythian.com/blogs

--
http://www.freelists.org/webpage/oracle-l
Received on Thu May 25 2006 - 22:21:49 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US