We have only done this with our exchange servers (not the basic node but the
data from the exchange TDP).  On these systems we have three nodes
base_node, base_nodeA, and base_nodeM.  The base_node is for the operation
system.  The "A" is the current exchange node.  If told to lock, we will
change to base_nodeB for that point on and then "C" and such.  The "M" node
is for the TDP but a monthly backup which we have to keep forever (for now
anyway).   We put them in their own pools (we make pools to match the last
letter of the name) and change node names when they have to be locked up as
described above.  We in effect do number (5).  Note that you do not have to
rebind/reset the management classes to longer retention because the node
that is locked will never backup again.  Thus with no backups there is no
deletes or expires.

Seems to work for us.  It is a pain.  I can not imagine if we had to do all
nodes.


--
Phillip Ford
Senior Software Specialist
Corporate Computer Center
Schering-Plough Corp.
(901) 320-4462
(901) 320-4856 FAX
phillip.ford AT spcorp DOT com




-----Original Message-----
From: bbullock [mailto:bbullock AT MICRON DOT COM]
Sent: Thursday, August 15, 2002 2: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

***************************************************************
 This message and any attachments is solely for the intended recipient. If
you are not the intended recipient, disclosure, copying, use, or
distribution of the information included in this message is prohibited --
please immediately and permanently delete this message.