Reusedelay

[tsmuser10]

just a quick question. I have resusedelay set for 7 on copypool and dbexpire to 7 . is it ok to keep the primary pool at 0 or should they match also ?

 

[toxy13]

it's ok, why you have a bigger value for your copypool tapes?

 

[tsmuser10]

I've read in many places that the resusedelay and drmdbexpire should match

 

[toxy13]

thats right, but why have your "copy stg pool" such a big reusedelay?

I think you can use for primary and copy stg a reusedelay for 1 day.

 

[tsmuser10]

I'm looking into setting it @3 and keeping the primary at 0

 

[toxy13]

sounds good!

copystg reuse: 3
primastg reuse: 0

 

[tsmuser10]

One other question, since DRM is managing this the copy & prime reuse should not be the same ?

 

[tsmuser10]

OK I found it, this is what I was looking for (admin guide who who of thought)

If you back up your primary storage pools, set the REUSEDELAY parameter for the primary storage pools to 0 to efficiently reuse primary scratch volumes. For your copy storage pools, you should delay reuse of volumes for as long as you keep your oldest database backup.

 

[GregE]

This is so you can go back to your TSM database and the references to files on those tapes are still valid since the tapes haven't been reused in the same amount of time.

A scenario for going back X days would be a DR test. We just finished one, and management decided on a recovery point that was about 10 days before the actual test begin date so all tapes are offsite with a database that contains object pointers to everything on those tapes. I had to set mine, for this, to 18 (uugh) because we had a primary recovery date, and a secondary even older if for some reason the primary date wasn't a go.

 

[crazymad]

I'd be a bit careful here. If you have reuse set to 0 on the primary pool, then when you restore older DB, your primary stg pool won't be valid anymore. So you should mark it as destroyed and recover it from the copy pool. You could also audit volumes on the primary STG, but if some data was overwritten, it would erase them (with fix=yes) from DB, thus even from copy pool.

So yes, it's fine. But keep in mind, you shouldn't use primary pool anymore after DB restore..

 

[icewalker]

If you perform a true DR Test, you will notice the scripts on your remote TSM Server do destroy your primary storage pools (a problem for us because we use Dedup's here and at colo, so not all "primary storage is destroyed"). So yes, with Tapes, your copypool reusedelay should be at least the same as your database retention.

If you do like us and use a Deduplication device that mirrors to your colo site, you have to be careful with your primary storage pools as well. One little space reclamation with a reusedelay of 0 could ruin your RTO (Recovery Time Objective). So our primary storage pools on the Dedup are also set the same as the copypool tapes (which sucks, but is necessary for speed of recovery).