Is reclamation retroactive ?

[ldmwndletsm]

We have a tape storage pool that does not have reclamation enabled. Specifically, the reclamation threshold=100, and the copy group settings (verexists, verdeleted, retextra, retonly) have 'No Limit', so no objects ever expire. Moreover, the corresponding copy pool is likewise the same.

Question: If we change the Copy Group settings to have limited (finite) values (something reasonable), and we set the reclamation threshold to < 100 (e.g. 50), then will this only affect backups going forward and not the data that's already been written to tape -- specifically full tapes ?

IMPORTANT NOTE: The reason for the question is because some time ago, we ejected a number of full tapes in this primary storage pool and stored them on site to free up tape storage slots in the tape library. This worked like a champ because reclamation is not used on that storage pool or the corresponding copy pool, although we do use it on others. The only reason we've ever had to reload those tapes has been to restore or conduct a test. However, for sustainment planning, we wanted to know if enabling reclamation would involve having to reload those tapes. The most recent last write date on any of those shelved tapes is a while ago. I suspect that such a change would not be retroactive, but if it is then that will change our planning as we will then have to accommodate all those tapes, thus requiring a slot license upgrade above what we were otherwise anticipating for our other primary pools where reclamation is being used (those other tapes remain in the tape library).

In the event that it's relevant, collocation by group is used on the primary pool in question, but collocation is not used on the corresponding copy pool.

 

[ldmwndletsm]

Based on this IBM document (below link), it sounds like changes to the copy group settings would be retroactive, affecting both new data backed up, following any changes, as well as data already being tracked in the database from before the changes:

Changing Backup and Archive retention values for copy group.

So if the retextra or retonly values are changed then the next time the expiration process runs, data could expire. For verexists and verdeleted, another backup will have to occur. But based on the information in the "update copy group" command, an inactive version could expire based on retextra, thus overriding verexists and/or verdeleted.

I might have to check with IBM to see if a prior value of 'No limit' would somehow alter this. Otherwise, it would seem that enabling reclamation could very well be retroactive given that one or more of the copy group settings would first have to be changed to a finite value (never mind the reclamation threshold, natch), and once that happens, the possibility is introduced that one or more erstwhile "No Limit" objects could expire, and if the reclamation threshold for the affected volume is satisfied then TSM would reclaim it. Of course, it could not do that if the tape wasn't in the tape library, but it would complain every day until it could access it, so it's gonna want to reclaim it. That would mean that any of those volumes that were previously removed from the tape library could conceivably be reclaimed at any point thereafter and would thus need to be reloaded and always kept in there.