Your scenario is EXACTLY what REUSEDELAY is designed to prevent. Use it or lose it!
-----Original Message----- From: Bill Mansfield [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 09, 2004 8:03 AM To: [EMAIL PROTECTED] 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
