RE: Database Retention Question

From: Scott Canaan <srcdco@xxxxxxx>
To: "rs350z@xxxxxx" <rs350z@xxxxxx>
Date: Mon, 1 May 2017 13:11:44 +0000

Yes, but we would back up the snapshot.  At least it will contain the O/S and
Oracle software, in working order.

Scott Canaan ’88 (srcdco@xxxxxxx<mailto:srcdco@xxxxxxx>)
(585) 475-7886 – work                (585) 339-8659 – cell
“Life is like a sewer, what you get out of it depends on what you put into it.”
– Tom Lehrer

From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On ;
Behalf Of RDS
Sent: Monday, May 01, 2017 9:08 AM
To: Scott Canaan
Cc: Reen, Elizabeth; oracle-l@xxxxxxxxxxxxx
Subject: Re: Database Retention Question

Snapshots are not backups! If you take a snapshot then perform a backup on that
snapshot, not sure what you are buying yourself over just backing up the
original databases. A snapshot is a point in time entity and this snapshot is
dependent on the underlying storage, it is not a copy of the data, so if you
lose your storage, you lose your data. Also what people don’t realize is that
if you perform IO against a snapshot, say surface a database from this
snapshot, you are performing IO on the same disks that your original databases
are running on.

On May 1, 2017, at 8:58 AM, Scott Canaan
<srcdco@xxxxxxx<mailto:srcdco@xxxxxxx>> wrote:

This was one of the first things we thought of, however there are 28 backups to
keep running (4 databases x 7 days each), which becomes unwieldly very quickly.

What we are looking at doing is putting all 4 databases into one VM, then
taking a VM snapshot of the entire environment, which gets us down to 7
snapshots to save and that way the O/S and Oracle software are also preserved
with the databases.  That’s what I’ve gathered from the responses here is the
best way to go.

Scott Canaan ’88 (srcdco@xxxxxxx<mailto:srcdco@xxxxxxx>)
(585) 475-7886 – work                (585) 339-8659 – cell
“Life is like a sewer, what you get out of it depends on what you put into it.”
– Tom Lehrer

From: Reen, Elizabeth [mailto:elizabeth.reen@xxxxxxxx]
Sent: Friday, April 28, 2017 4:29 PM
To: Scott Canaan; oracle-l@xxxxxxxxxxxxx<mailto:oracle-l@xxxxxxxxxxxxx>
Subject: RE: Database Retention Question

            What I have ended up doing is just keeping the copy on a database,
upgrading and patching as needed.  Expensive, yes.  Data always available, yes.
What you have to lose if you lose the case should dictate how you keep the
data.

Liz

Elizabeth Reen
CPB Database Group Manager

From: oracle-l-bounce@xxxxxxxxxxxxx<mailto:oracle-l-bounce@xxxxxxxxxxxxx>
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Scott Canaan
Sent: Thursday, April 27, 2017 1:16 PM
To: oracle-l@xxxxxxxxxxxxx<mailto:oracle-l@xxxxxxxxxxxxx>
Subject: Database Retention Question

We are trying to find a workable solution to a rather large problem.  One
system has an Oracle database in Red Hat 6 and Oracle 11.2.0.4.  Last August,
there was a legal request to freeze 28 different backups of this database.
That was done by the systems team, via CommVault (using RMAN).  By asking more
questions, it has come to light that any and / or all of those backups need to
be quickly accessible as Oracle databases until Aug. 31, 2023.  When I
mentioned to our legal department that there’s no way that I can guarantee that
whatever version of Oracle we’ll be using in 5, 6, 7 years will be able to even
open the database files, the response was “you have to guarantee that the data
is available if required in a lawsuit.  No excuses are accepted by the courts.”.

We’ve toyed with a couple of possible options.  One is to keep a Red Hat 6 /
Oracle 11.2.0.4 environment running until Sept. 1, 2023, which the SAs hate
(not to mention the Security Office).  Another is to restore from backup and
upgrade along with other database upgrades and take a new frozen backup, which
we aren’t keen on doing 28 times.

Does anyone have any other ideas on how to save these backups and guarantee
that they are usable through Aug. 31, 2023?  I’d appreciate any thoughts.

Thank you,

Scott Canaan ’88 (srcdco@xxxxxxx<mailto:srcdco@xxxxxxx>)
(585) 475-7886 – work                (585) 339-8659 – cell
“Life is like a sewer, what you get out of it depends on what you put into it.”
– Tom Lehrer

Rick Stehno
[cid:image001.png@01D2C25A.F427F430]

References:
- RE: Database Retention Question
  - From: Scott Canaan
- Re: Database Retention Question
  - From: RDS

RE: Database Retention Question

Other related posts: