Your scenario is EXACTLY what REUSEDELAY is designed to prevent.
Use it or lose it!

-----Original Message-----
From: Bill Mansfield [mailto:WMansfield AT SOLUTIONTECHNOLOGY DOT COM]
Sent: Wednesday, June 09, 2004 8:03 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Reclamation data loss scenario


We were documenting some TSM server recovery scenarios the other day,
and came up with one I haven't seen discussed before.  Here's the
scenario:

Client backups finish, storage pool backups finish, TSM DB backup
finishes, prepare run.
Expiration runs.
Primary tapepool reclamation reclaims tapes A and B, moving content to
tape C (was scratch).
Diskpool migration runs, starts moving data to tapepool tapes A and B.
DISK FAILURE wipes out database and log (but not storage pools).
Get new disk, restore server from TSM DB backup tape.

At this point everything looks ok, but I actually have two "corrupt"
tapepool tapes (A and B),
and I'm not too sure the diskpool is any good either.

The question is, what do we need to put in the recovery procedure to
handle this?
I can probably prevent it by setting reusedelay on the tapepool, but we're
short
on tape slots most of the time, and letting the reclaimed tapes pend until
the
oldest DB backup expires like we do our copypool tapes would overflow the
library.

I know I can audit and recover the tapes from the copypool, but the
problem is
I have hundreds of tapes, and insufficient time and tape drives to audit
them all,
and no sure way to tell which might need auditing.

BTW, we've taken steps to better protect the TSM DB and Log disk, but this
scenario
lingers like a bad smell.

Thanks in advance!

Bill Mansfield