RE: Secure backup?
Date: Wed, 29 Apr 2009 12:27:21 -0400
I want to be clear that I have not personally managed backups in some years. However I have advised several clients on this issue.
The simplest thing to do is have a group that gets read only access of some form to production/DR and is responsible for periodic recoverable backups from that point forward.
If you have DR you can place the fence between production and DR. Combining that with immediate shipping of logs and a delay in application of the logs to that particular DR gives you the best protection for getting valid data up to the point of the "insane act."
Nothing on God's green earth can protect you completely if an "insane actor" or a broken program makes small changes to production data interspersed with valid transactions. Appropriate auditing can restrict the duration of the bad changes, and it is probable that with some work the "valid to a known point" DR database can be combined with the valid transactions to produce a "good enough to survive" database result.
If the bulk of changes to your system are captured as logical units of work or transactions in a way that can be replayed, it can be very effective to re-apply the captured transactions beginning from the known good point recovered from the delayed application DR. This can be either with a repaired program or an excluded "insane actor", and then you are only left with the lost legitimate interactive transactions not captured to apply (as might be the case if the bulk of your transactions were some sort of batch feeder collection system, but some transactions were from forms not outfitted with transaction dumping.) Log mining non-captured transactions might well get you completely restored.
This protocol worked quite well when I was asked to help recover (again, some years ago) after two separate events.
One was loss of the disk farm combined with the discovery that the vendor's tape library catalog spilled new entries to the bit bucket without error messages once it was full, so the interthatched tapes could not be read to produce the original files, even though the tapes read after writing just fine.
The second was in fact a seriously broken application program.
At the end of the day, we lost zero data from these two escapades. That does not mean the protocol is bulletproof.
Fortunately I have never had to deal with the "insane actor" problem on a real database. I claim that preventing an arbitrarily clever person with authority from doing harm to your database is an NP incomplete problem, and the correct solution is to understand that and implement something in the region of acceptable risk and acceptable cost of insurance.
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of Zhu,Chao
Sent: Wednesday, April 29, 2009 10:56 AM To: ORACLE-L
Subject: Secure backup?
Our company is now thinking about *Secure* backup, which means not a single DBA/SA have access to all the production/DR (and 3rd online copy).
Currently our implementation is every DBA/SA have access/control over every copy of database. It has been working Ok for 10+ years, but we are thinking about potential issue;
It makes life easy when every DBA has access and can manage every database copy. But if something goes wrong with someone, he has the power to bring the company down(today's business has been relying so much on IT infrastructure); And management team wanted to address this potential issue(It is like DR, never happens, we hope:), but we need to address it).
Can someone share how you do that in your organization? Like have dedicated DBA/SA manage the database backup (So he has no access to production database, and production DBA has no access to backup copy)? or with some 3rd party products like storage snapshot like netapp or other storage vendors?
Any comment is appreciated.
-- Regards Zhu Chao www.cnoug.org -- http://www.freelists.org/webpage/oracle-lReceived on Wed Apr 29 2009 - 11:27:21 CDT