TSM v4.1 for AIX, Administrator's Guide, Table 27 (Table 22 in Windows guide, Table 26 for Solaris) "NOLIMIT/NOLIMIT 60 days/180 days Retain Extra Versions controls expiration of the versions. The server does not expire inactive versions based on the maximum number of backup copies. The inactive versions (other than the last remaining version) are expired when they have been inactive for 60 days. If the user deletes the REPORT.TXT file from the client node, the server notes the deletion at the next full incremental backup of the client node. >From that point, the Retain Only Version parameter also has an effect. All versions are now inactive. The three of four versions will expire after each of them has been inactive for 60 days. The server keeps the last remaining inactive version, the April 23 version, for 180 days after it becomes inactive. "
The special treatment is only for the last version (i.e. the active version before the deletion). It becomes inactive at the time of deletion which is the SAME as becoming the only version! At this moment it 'gets bonus' of 7 (21-14) days. The rest in David's answer is correct: at the 14-th day it is time all but last versions to dismiss and the last version will stay for total of 21 days, i.e. only 7 days more (14 already passed). "So there is no reason to ever set retain only to less then retain extra, right?" I dunno :-O Both documentation and redbooks (SG24-5416-01) are silent on this. In the redbook we can find only the following: "VERDELETED: Specifies the number of file copies to keep after the file has been deleted. This must be equal to or less than VEREXISTS. RETONLY: Specifies how long to maintain the last file copy of the data. This is the number of days to keep the last remaining copy only, and does not apply to other inactive file copies which are still governed by the RETEXTRA parameter. This parameter can also be set to NOLIMIT which means the last remaining copy is never expired." So only verdeleted is discussed. However I was able to define a copy group with verexist=2 verdeleted=5 retextra=60 and retonly=1. Neither copygroup define nor policyset activation complained. A file was backed up five times using the management class with so defined copygroup. After this the file was deleted and expired. All five copies were in the pool but after inventory expiration only two copies remain. I will check it tomorrow again to see what is expired and what is not. Results on TSM 4.1.4.1/AIX 4.3.3ML6 Zlatko Krastev IT Consultant David Bronder <[EMAIL PROTECTED]> on 13.11.2001 22:18:24 Please respond to David Bronder <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: Re: Re: Data Retention Based on how the original question was worded, both Mark's and Bill's answers below are incorrect. The last version expires 21 days after it went _inactive_, not after it became the the only version. In the original question, 14 days have passed since the file was deleted (and went inactive), leaving 7 more days before the last version is deleted in TSM (for a total of 21 days). If that isn't how TSM behaves, then the documentation is wrong. =Dave Mark Stapleton wrote: > > On Tue, 13 Nov 2001 10:14:31 -0800, it was written: > >Versions data exists - nolimit > >Versions data deleted - nolimit > >Retain extra versions - 14 > >Retain only versions - 21 > > > >When a version is deleted from the server and after 14 days have passed, > >is the "only" version retained for 7 more days or for 21 more days? > > The retain only version's clock doesn't start running until it does > into effect. Hence, the answer is "21". Bill Mansfield wrote: > > 21 days. According to Table 17 in the admin guide, the RETONLY clock > starts ticking when the file goes inactive, which happens during the first > backup after the file is deleted from server storage. -- Hello World. David Bronder - Systems Admin Segmentation Fault ITS-SPA, Univ. of Iowa Core dumped, disk trashed, quota filled, soda warm. [EMAIL PROTECTED] Gerald Wichmann <[EMAIL PROTECTED]> on 13.11.2001 23:10:24 Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: Re: Data Retention So there is no reason to ever set retain only to less then retain extra right? Gerald Wichmann System Engineer StorageLink 408-844-8893 (v) 408-844-9801 (f)
