Will changing copy group settings be retroactive ?

[ldmwndletsm]

This is similar to my other post about reclamation, but I'm making this a separate one in case there are different considerations or constraints.

We have a tape storage pool with copy group settings (verexists, verdeleted, retextra, retonly) = 'No Limit', so no objects ever expire. Moreover, the corresponding copy pool is likewise the same. The reclamation threshold is 100 for both storage pools.
Obviously, reclamation never occurs, as we would expect.

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

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.


I'm tempted to think that data that's already been backed up using the current settings will not be affected, and, of course, such data could be manually addressed if desired, but I'm not certain here with retroactivity as TSM seems to always have some surprises.

 

[ldmwndletsm]

Based on this IBM document (below link), it sounds like it 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.