ailto:[EMAIL PROTECTED]
Sent: Friday, June 11, 2004 8:57 AM
To: [EMAIL PROTECTED]
Subject: Re: Reclamation data loss scenario
Richard,
You're right, of course, but in this case Bill was trying to balance risk
of corrupted primary tapes vs. shortage of media. I sometimes find myself
in the same
spond to "ADSM: Dist Stor Manager"
To: [EMAIL PROTECTED]
cc:
Subject:Re: Reclamation data loss scenario
>You really only need to set the reuse delay long enough to ensure that
you
>have at least one good DB backup before reusing the volume. ...
>You really only need to set the reuse delay long enough to ensure that you
>have at least one good DB backup before reusing the volume. ...
That reminds me of the scene in The Court Jester where a knight pushes
Danny Kaye out of the spot where lightning is about to strike. :-))
Our reality is th
quot;
To: [EMAIL PROTECTED]
cc:
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, st
r 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
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
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On
Behalf Of Richard Sims
>...
>>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 l
...
>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
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
