You are correct, the data in the primary pool and the copypool would
be expired on the production database. Since the copypool tapes are not
being reclaimed, the data will still intact on the copypool tapes, it's just
that the production database no longer knows where it is. With the DBBackup
we take and set aside, ~that~ DB will have pointers to the data on the
un-reclaimed copypool tapes.
So in the case of a restore from of that older data, I would have to
restore the old database (to a test host) attach it to a drive, mark the
primary tapes as unavailable and feed the old copypool tapes into the
library during the restore.
That's my theory at this point.
Ben
-----Original Message-----
From: Ramnarayan, Sean A [EDS] [mailto:SARamnarayan AT CALTEX DOT COM]
Sent: Friday, August 16, 2002 4:09 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Eternal Data retention brainstorming.....
Hi
I have just a question ?
When you use the reuse delay option and set it to 9999 on your copypools ,
what happens to the data if you have a management class which expires the
data from your primary pool, the data on your copy pool will automatically
be expired, so which ADSM/TSM database backup would you use to restore your
data.
I just need to know as I need to do set up a policy similar to the one you
require.
Thks
Sean Ramnarayan
EDS (South Africa)
-----Original Message-----
From: bbullock [mailto:bbullock AT MICRON DOT COM]
Sent: Friday, August 16, 2002 1:54 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Eternal Data retention brainstorming.....
Dang, my mails are long-winded. Forgive me if I'm boring those of
you who are not interested. Fell free to use the "delete" button. :-)
There's been a lot of good suggestions sent to me. The real kicker
is that with the volume of data involved (460TB as of today), some of the
solutions do not scale well, in that they will take months to complete, or
cost $100,000s in tapes to execute.
Like most of you out there, we gradually grew to our current size,
and management can take the constant nickel and diming we do to keep ahead
of the capacity curve. A big $$ expenditure to CYA for a "what if" will not
sit well with management and they will look to me for "creative
alternatives".
I actually called Tivoli and discussed it with a level 1 & 2 and
here's what I/we came up with.
We have 2 kinds of data: Mission Critical data that we keep in a
copypool, and non-critical/old data we do not backup to a copypool.
Unfortunaly, ALL of the data needs to be retained and the non-critical
(unduplicated) portion is rather substantial in size.
Here's a 1000-ft view of what we are thinking about:
Take a backup of the TSM DB. Make it so that copypool tapes will
never be reused "reusedelay=9999". As production rolls on, all copypool
tapes will be taken from scratch, so the old data we are trying to retain
should remain on the copypool tapes, although at some time, the production
DB may remove their BD pointers through it's "expire inventory" process. Our
growth in copypool tapes is much more reasonable (10-20 tapes a week), and
not costly enough to freak management out.
In the case of the old data being needed, the TSM database can be
restored on a test host & the primary tape volumes marked as inactive. When
a restore is needed, the TSM server will request the copypool tapes, and the
data will still be intact because they have not been re-used. This portion
is pretty much like a disaster recovery test.
The non-critical data is a little harder, as there is only 1 copy of
the data. We could try to push it to a copypool, but there is a LOT and it
will take quite a bit of time $ money. The good thing is that this data is
~only~ being retained for the investigation and no other purpose. For this
reason, daily operations, and file restores will ~never~ need these tapes.
We will check all these primary tapes out of the library at the same
time we take the DB snapshot and box them up with BIG RED letters and put
behind a barber wire fence guarded by vicious dogs. We will then mark the
tapes as DESTROYED on our production database. We might even delete the
filespace, as they are just that useless, however we are going through all
this trouble because they are required because "ALL BACKUPS/ARCHIVES" are
required to be retained.
If we need to restore data off of one of these tapes, we will
restore the TSM DB backup to our test host. These tapes should all still be
marked as "readw" on the restored DB, so we should just be able to restore
the data by feeding it the primary tapes it requests.
Benefits:
- No need to duplicate the data with a "export data" or making a 3rd
copypool copy.
- Very little extra $$.
Problems:
- More work and time up front to make sure it works as planned.
- Care needs to be taken and procedures in place so that copypool or
primary "useless data" tapes are not accidentally reclaimed.
- Might interfere in a true disaster, as the copypool tapes might be
in the wrong place because of an "investigation related" restore.
What do you think? Does it sound like it would work? I ~think~ it
sounds do-able. Am I missing a big GOTCHA anyone can see?
Thanks,
Ben
"MMS <caltex.com>" made the following
annotations on 08/16/2002 12:09:01 PM
----------------------------------------------------------------------------
--
DISCLAIMER
This message may contain confidential information that is legally privileged
and is intended only for the use of the parties to whom it is addressed. If
you are not an intended recipient, you are hereby notified that any
disclosure, copying, distribution or use of any information in this message
is strictly prohibited. If you have received this message in error, please
notify the sender immediately and delete the message. Thank you.
============================================================================
==
|
