On Nov 6, 2008, at 4:05 AM, Craig TSM wrote:
Interesting, I am aware of the deactivation time you mentioned. Now its been a while but from what I remember changing the policy retention either by changing current or moving node to another, did not change this deactivation date, remembering this is what I found for files which were already deleted from client , and expiration has run across TSM DB. So what your saying is certainly true for active / non deleted files from client. Of course the original issue raised I believe files were still on client. So no concern.
The flagging of a file as deactivated is irrevocable. Extending the retention period can serve to extend the residency lifetime of deactivated files, as qualified below.
Also I discovered even if Expiration processing is stopped (which I don't recommend) once the Deactivation date is reached, you cannot restore the file!!!
You're confusing deactivation with expiration. A deactivated file is one which has gone from Active to Inactive. Inactive files can certainly be restored, until... Stored objects reach end of life either by being pushed out by versions overflow or deactivation date + retention. In the case of end of life, TSM server internal periodic processing identifies client objects whose time is up, and changes their deactivation date to a "negative infinity" value to mark them as goners, and adds their identity to the internal table called Expiring.Objects, whose contents are processed by Expire Inventory. A file thusly marked will no longer be revealed in queries or restoration candidate lists. It is a deactivated file which is marked for elimination which cannot be restored. Richard Sims http://people.bu.edu/rbs
