Wanda,
Thanks for the input. The last suggestion of starting over had
crossed my mind, but I forgot to include it in my list. I guess the reason I
left it out was that with 800 clients, (some of them large) and with HSM in
place, starting from scratch would be difficult. Then, the hardware (8
high-end RS6000s would be hard to afford).
I have since looked at option 4 a little closer and refined it
further. All the data is duplicated in copypools, right? So, what if I took
a snapshot of the database and kept it aside. I then could change the
"reusedelay" to 999 on the tapes in the copypool so that they will not be
overwritten. That way I won't have to make an additional copy of the data as
I already have one. Sure, tape usage will still go up as the copypool tapes
are never reclaimed, but it would not instantly double as they do in the
other scenarios.
It kind of sounds like a disaster recovery test if I were to need to
restore the old data. I'd restore the DB to a test host, gather up the
copypool tapes and try to restore something. I could hit 2 birds with one
stone (meet the legal requirements and do a DR test).
Thanks,
Ben
-----Original Message-----
From: Prather, Wanda [mailto:Wanda.Prather AT JHUAPL DOT EDU]
Sent: Thursday, August 15, 2002 2:09 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Eternal Data retention brainstorming.....
Well, this is an interesting "what-if" scenario for discussion!
I'll take a crack at it...
1) Painful, but may be the best solution overall.
2) I don't think that will work. Turning off EXPIRE INVENTORY will prevent
your tapes from reclaiming, but if you have a mgmt class set to 5 versions,
I think the 6th backup will still make the 1st version invisible to the
client. Test it and see.
3) Doesn't exist.
4) I think that would work.
5) I guess that would work, but what would be accomplished by using the new
domains?
Result is the same (I think) as just setting the existing management classes
in the existing domains to never expire/unlimited versions.
And, if you don't have the same management classes in the new domains as the
old, when you move a client to a new domain you get a lot of errors, and the
files get managed by the "grace period" numbers, anyway. Nothing good will
happen.
Export may be the cheapest solution, overall, although it's gonna get
expensive fast since you will quickly double your tape requirements.
1) Change all your management classes to never expire/unlimited versions
2) Make sure NONE of your clients has the delete-backup-data privilege
3) Start your exports, take your time doing them.
When done, you have a complete set of data that is external to TSM.
You can set up a test server with a small TSM, and do IMPORTS of specific
clients as needed, if the investigating agencies ever figure out what they
want to look at. (Careful to have your mgmt classes set to never
expire/unlimited versions when doing the imports.)
THEN you can reset your production system back to normal retention periods,
and TSM will purge itself of the built-up extra stuff and move on.
Besides that, the best solution I can think of, change all the management
classes to never expire/unlimited versions,
Copy the DB to your "test" server, lock all the client nodes, put your tapes
on a shelf.
Save the last DB backup, just in case.
Start your production server over with a clean DB, back up everything new
and move on.
If anybody needs their old stuff, get a copy via export (from test) and
import(back to production).
That would keep you from (immediately) doubling your tape requirements, will
cost you some hardware to make tape available for your test system..
************************************************************************
Wanda Prather
The Johns Hopkins Applied Physics Lab
443-778-8769
wanda_prather AT jhuapl DOT edu
"Intelligence has much less practical application than you'd think" -
Scott Adams/Dilbert
************************************************************************
-----Original Message-----
From: bbullock [mailto:bbullock AT MICRON DOT COM]
Sent: Thursday, August 15, 2002 3:31 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Eternal Data retention brainstorming.....
Folks,
I have a theoretical question about retaining TSM data in an unusual
way. Let me explain.
Lets say legal comes to you and says that we need to keep all TSM
data backed up to a certain date, because of some legal investigation
(NAFTA, FBI, NSA, MIB, insert your favorite govt. entity here). They want a
snapshot saved of the data in TSM on that date.
Anybody out there ever encounter that yet?
On other backup products that are not as sophisticated as TSM, you
just pull the tapes, set them aside and use new tapes. With TSM and it's
database, it's not that simple. Pulling the tapes will do nothing, as the
data will still expire from the database.
The most obvious way to do this would be to:
1. Export the data to tapes & store them in a safe location till some day.
This looks like the best way on the surface, but with over 400TB of data in
our TSM environment, it would take a long time to get done and cost a lot if
they could not come up with a list of hosts/filespaces they are interested
in.
Assuming #1 is unfeasible, I'm exploring other more complex ideas.
These are rough and perhaps not thought through all the way, so feel free to
pick them apart.
2. Turn off "expire inventory" until the investigation is complete. This one
is really scary as who knows how long an investigation will take, and the
TSM databases and tape usage would grow very rapidly.
3. Run some 'as-yet-unknown' "expire inventory" option that will only expire
data backed up ~since~ the date in question.
4. Make a copy of the TSM database and save it. Set the "reuse delay" on all
the storage pools to "999", so that old data on tapes will not be
overwritten.
In this case, the volume of tapes would still grow (and need to
perhaps be stored out side of the tape libraries), but the database would
remain stable because data is still expiring on the "real" TSM database.
To restore the data from one of those old tapes would be complex, as
I would need to restore the database to a test host, connect it to a drive
and "pretend" to be the real TSM server and restore the older data.
5. Create new domains on the TSM server (duplicates of the current domains).
Move all the nodes to the new domains (using the 'update node ...
-domain=..' ). Change all the retentions for data in the old domains to
never expire. I'm kind of unclear on how the data would react to this. Would
it be re-bound to the new management classes in the new domain? If the
management classes were called the same, would the data expire anyways?
Any other great ideas out there on how to accomplish this?
Thanks,
Ben
|
