ADSM-L

Re: Eternal Data retention brainstorming.....

2002-08-16 06:01:46
Subject: Re: Eternal Data retention brainstorming.....
From: Remco Post <r.post AT SARA DOT NL>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 16 Aug 2002 12:03:04 +0200
Have you considdered using archiving to store the data that needs to be
kept forever? I've very sure no government org is really intrested in
your /etc/passwd file for over 1o years back. Find out what you need to
keep and set up archiving....

On donderdag, augustus 15, 2002, at 09:30 , bbullock wrote:

        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

---
Met vriendelijke groeten,

Remco Post

SARA - Stichting Academisch Rekencentrum Amsterdam    http://www.sara.nl
High Performance Computing  Tel. +31 20 592 8008    Fax. +31 20 668 3167

"I really didn't foresee the Internet. But then, neither did the computer
industry. Not that that tells us very much of course - the computer
industry
didn't even foresee that the century was going to end." -- Douglas Adams