Very well written !!!
May I slightly improve it:
1. Mark diskpool volumes read-only. Migrate disk pools and mark all
primary volumes read-only (or only ones which do not have copypool
backups). Check out all read-only tapes.
2. Like your step 1 but take only one db backup. The rest as described in
several copies. Do not forget OS and TSM documentation CDs (five years
later several investigators were changed and none of them knows what TSM
is and how to beat it - let them RTFM).
3. Mark diskpool volumes back to read-write.
4. Set up a test server. Disable expiration, restore the (only) DB backup,
modify all mgmtclasses/copygroups/stgpools. Mark primary tapes (of
backed-up "important" stgpools) unavailable. Backup the DB.

If cannot afford additional cartridges or investigation is supposed to be
short-term - make few more DB backups; set reuse delay on production
server's pools to 9999. "Non-important" primary volumes and "important"
copypool volumes hold the data for both production and "investigation"
servers. Sit and wait this to finish sooner. Skip steps 5-10, ensure step
11 is done and do not dream about step 12.
If forced to keep the data long-term regardless the price:
5. Backup to copypool(s) even the "non-important" (non-backed up) storage
pools. Check-in (read-only) primary volumes in production server's library
and mark back to read-write (in production DB) for normal day-to-day
operations.
6. Mark all primary volumes unavailable and restore primary pools on the
test server (it now became DR test server :).
7. Return (production) copypool volumes to vault for normal DR. Delete
volumes from DR test server and backup all affected pool to make copies
for "investigation" DR.
8. Make additional copypool copies if necessary for very-long-term data
retension.
9. Backup the DB several times.
10. As your step 2.
11. Get signature from Legal as Tab pointed that he/she understands how
TSM is working and will not bother you to downgrade the production server.
12. Sit back and relax - you've done the task and covered your aZZ :)

Zlatko Krastev
IT Consultant




Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Sent by:        "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To:     ADSM-L AT VM.MARIST DOT EDU
cc:

Subject:        Re: Eternal Data retention brainstorming.....

What kind of shelf life are you expecting for your media?  Since they've
discovered that optical has data decay, it's not even "forever"!  I've
seen
some others on the list point at it, but how will you restore this data in
10 years?

Here's what I'd look at doing:

1.  Take about 5 dbbackups (or snapshots) and send them to the vault. Take
a few OS level backups of your server (bootable tape images).  Send them,
too.  Send volhist, devconfig, a prepare file, TSM server and client code,
OS install code, everything else that makes your environment your
environment, including the clients, offsite.  This is DR - in the most
extreme sense of the term.
2.  Box up the vault.  Seal the boxes, leave them there.
3.  Start marking offsite volumes as destroyed (or just delete them) in
TSM, and run more Backup Stgpools.  They'll run longer, as you're
recreating the old tapes.
4.  Go back to step 1 and repeat once.  If this data is really that
important to have forever, make sure you can get it back!
5.  Start sleeping - you're going to be WAY behind on that!

Now, for the people making the requirement - they need to get a contract
to
have accessible like hardware to do the restores to.  Not just the TSM
server and tape library, but the clients, too.

Having the data available is one thing, being able to restore it is
another.

Nick Cassimatis
nickpc AT us.ibm DOT com

Today is the tomorrow of yesterday.