RE: Secure backup?

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.

 

Regards,

 

mwf

 

 

 

  _____  

From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
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.
Thank you!
-- 
Regards
Zhu Chao
www.cnoug.org

Other related posts: