Re: Eternal Data retention brainstorming.....

I like Wanda's export solution the best.  It's not the ideal answer, and
(it's been my experience that) many customers don't care about the inactive
versions, just the archives (snapshots of the db's) and the active versions
of file served data... so, you could export only the active versions.

I worked with a customer that had abit of this issue -- the recommended
solution was to start a new TSM server, with a new db;  the old server just
stops getting used, all mgmtclass retention is set to the length of time
requested, so it becomes a stand-by, restore-only instance of the TSM db --
doesn't need to be started unless a restore request comes in.  With this
solution, the db stops growing, the data continues to be available, the
policy domain/mgmt-class update produces the desired retention -- and, with
no new data, expiration process does not need to run, at all,,, hence,
preserving visibility of the inactive versions(even if you fail to change
retention!).

Don France
Technical Architect -- Tivoli Certified Consultant
Tivoli Storage Manager, WinNT/2K, AIX/Unix, OS/390
San Jose, Ca
(408) 257-3037
mailto:don_france AT att DOT net

Professional Association of Contract Employees
(P.A.C.E. -- www.pacepros.com)



-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
bbullock
Sent: Thursday, August 15, 2002 1:45 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Eternal Data retention brainstorming.....


        True, that would keep the last active versions, but in this case
they want everything that was backed up to TSM as of a certain date, even
the inactive versions. If I rename the filesystem, the inactive versions
will still drop off as the expire inventory progresses. :-(

Ben

-----Original Message-----
From: Doug Thorneycroft [mailto:dthorneycroft AT lacsd DOT org]
Sent: Thursday, August 15, 2002 2:30 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Eternal Data retention brainstorming.....


how about renaming the filespace, This will keep your active versions.

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