Well, I'm somewhere in between -
I set reusedelay to 0 for the primary pool, where I have limited slots in
the library. For the offsite pool I set reusedelay to the same as
DBBACKUPEXPIREDAYS, I have unlimited slots in offsite shelf storage.
I actually did have to roll the DB back one time to find something in a
crisis, then roll it forward again back to production level (yes it was a
big deal and took about 8 hours of down time, but it worked.) I figure this
way I'm covered.
> -----Original Message-----
> From: Kelly Lipp [SMTP:lipp AT STORSOL DOT COM]
> Sent: Tuesday, January 18, 2000 8:35 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Retention Periods for primary pools
>
> You are correct and I agree with your logic. I was more or less stating
> the
> standard which is 0 for primary pools. However, if you require a trip
> back
> in time on a regular basis, then your approach is sound. For trips back
> in
> time, I'd be tempted to use the copy storage pool and restore to another
> server. I don't think I'd want to take my production *SM server back in
> time, do my restore and then move forward again. Pretty much a hassle.
>
> Finally, if I ever did this more than once in my life, I'd seriously
> question my ability to set up *SM correctly in the first place (along with
> my sanity). In the cases where adequate planning wasn't done, I can see
> where a retention might have been shorter than necessary. But how long
> are
> db backups kept anyway? I've seen few sites where it was longer than a
> week. Usually when you realize retentions aren't right is about six
> months
> too late, not a week.
>
> What about a corrupt db backup? This might make it necessary to go back
> and
> in that case you could have a problem.
>
> I guess if you have slots to burn in the library, and I know I don't, I'd
> set reusedelay and db retention to be the same just to be safe.
> Otherwise,
> I'd probably stick with 0 and take my chances.
>
>
> Kelly J. Lipp
> Storage Solutions Specialists, Inc.
> PO Box 51313
> Colorado Springs CO 80919
> (719)531-5926
> Fax: (719)260-5991
> www.storsol.com
> lipp AT storsol DOT com
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
> Steve Harris
> Sent: Tuesday, January 18, 2000 5:17 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Retention Periods for primary pools
>
>
> Recently Kelly wrote
> "q stg f=d and look for the value of reusedelay. Typically, for primary
> storage pools set this value to 0."
>
> Kelly is usually right on the money, but I'd like to get straight about
> this.
>
> In many situations where there is a real disaster that destroys the *SM
> database
> the onsite primary tapes will also be unavailable or damaged. In these
> cases
> it
> is pointless to have reusedelay of other than zero. However, there are a
> range
> of real problems that could require a database restore and some of these
> will
> not necessarily manifest themselves immediately, requiring a reversion to
> a
> database backup earlier than the point of database corruption. Thus I set
> primary storagepool reusedelay to be the same as the dbbackup expiry time.
>
> I'm at a small site, and we have primary and offsite storagepools only:
> perhaps
> it is more usual to have primary/local copypool/offsite copypool setup, in
> which
> case this will be less of a problem as tapes don't have to come back from
> offsite.
>
> If I can convince myself that it is safe to do so, I would love to set the
> primary reusedelay to zero as it would remove the problem of pending tapes
> in
> our small library, and I could then run expiration more often.
>
> Discussion?
>
>
>
> Steve Harris
>
> AIX/ADSM/Oracle/HACMP Guy
>
> The Wesley Hospital, Brisbane, Australia
>
>
>
>
> ===========================================
> This email message has been swept by MIMESweeper
|
