Reusedelay + drm

BrianV

ADSM.ORG Member
Joined
Dec 13, 2011
Messages
83
Reaction score
3
Points
0
Location
USA
Hey all,

Still trying to clean up an environment which I inherited a year ago. We use DRM and I have noticed that tapes are not being consistently called back from our offsite location. Tapes will eject from the library but nothing is requested to come back 1 out of 5 times. I noticed that the copy pools are set to REUSEDELAY 0. Should this number be configured to our retention period (15 days) or should we just let DRM call back tapes as needed?

Brian
 
Reuse delay should be set to be equal or greater than the DB expire days.

I normally set to 3 days more than the db expire days. This assures me that I can recover the data if I have to restore the DB to an older version.
 
Thanks, moon-buddy. TSM support offered some advice but they made it really difficult to understand... It almost seems like he contradicted himself:

"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. 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 your primary storage pools should be set the same as the copypool tapes, this is necessary for speed of recovery."
He mentions at the beginning that primary should be set to 0 and copy set to whatever the DBB expire is yet contradicts that at the end. I'm a bit confused.
 
Thanks, moon-buddy. TSM support offered some advice but they made it really difficult to understand... It almost seems like he contradicted himself:

"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. 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 your primary storage pools should be set the same as the copypool tapes, this is necessary for speed of recovery."
He mentions at the beginning that primary should be set to 0 and copy set to whatever the DBB expire is yet contradicts that at the end. I'm a bit confused.

This is not a contradiction.

It is really what it should be. DR copies or the ones that goes offsite is your assurance that you can recover the data. The reuse for DR or copy tapes is set at the same or longer number of days you keep the TSM DB backup. If you keep the DB backup for 8 days, set reuse to 8 or 9 days for the DR or COPY tapes.

The online tapes - the ones left in the library - is set for reuse to ZERO.

This is what is normally done with TSM EE using DRM.
 
This is not a contradiction.

It is really what it should be. DR copies or the ones that goes offsite is your assurance that you can recover the data. The reuse for DR or copy tapes is set at the same or longer number of days you keep the TSM DB backup. If you keep the DB backup for 8 days, set reuse to 8 or 9 days for the DR or COPY tapes.

The online tapes - the ones left in the library - is set for reuse to ZERO.

This is what is normally done with TSM EE using DRM.

What you have said is correct, but what IBM have written still seems like a contradiction to me. The way I read what IBM wrote, was:
1. IBM said Primary Storage Pool Re-Use Delay set to 0
2. IBM then said Copy Storage Pool Re-Use Delay set to the same as the number of days you keep the TSM DB Backup
3. IBM then said Copy Storage Pool and Primary Storage Pool Re-Use Delay should be set the same

Did I read it wrong?

Cheers
 
Item 3 must be intended for something else or a simple typo - I believe it should read:

Copy Storage Pool reuse and DB Retention days should be set the same at minimum.
 
I read it the same way which is why it was a little confusing.
 
Can I update the storage pools or should I create new storage pools with the new REUSEDELAY setting then move the node data over?
 
Back
Top