Versions and retention periods
The retention periods as well as the number of versions of a file to be kept is determined by IBM Spectrum Protect (formerly TSM) by four sizes. These sizes cannot be influenced by the user. They are specified exclusively by the system administrator.
The following explanations do not apply to backups with the TDP clients.
In order to better understand the parameters, it is necessary to briefly explain what Spectrum Protect means by active or inactive versions of a file:
The active version is always the most recent, i.e. the last backup copy of a file, if - and this is very important - the original file still existed on the disk of the client concerned at the time of the last backup. The inactive versions are all predecessor copies of the active version and/or all backup copies if - and this is even more important - the original file no longer existed on the disk of the client concerned at the time of the last backup, i.e. has been deleted.
Now to the four sizes mentioned:
VEREXIST = N says that max. N backup copies are kept. (our value: VEREXIST = 3) RETEXTRA = N says that each backup copy, with the exception of the active version, which never expires, is kept for up to N days. are kept. We say up to, because the oldest copy always also immediately expires, regardless of RETEXTRA, if VEREXIST is exceeded. (our value: RETEXTRA = 62) VERDEL = N says that only the N-most recent backup copies will be kept backup copies will be kept, if Spectrum Protect has registered that the original the original file on the disk has been deleted. Attention: In this case the active version will also become an an inactive version! (our value: VERDEL = 1) RETONLY = N tells how many days the latest backup copy of a file will be kept file is kept when Spectrum Protect has registered that the original file on the original file on the disk has been deleted. (our value: RETONLY = 62)
The following 2 case studies should lighten up the "chaos" a bit:
The following parameters apply:
VEREXIST = 4 RETEXTRA = 45 VERDEL = 1 RETONLY = 62
1st case study - original file is not deleted
Day 1: Version 1 created Day 5: Version 2 created, version 1 becomes inactive and will expire in 45 days ( day 50 ). Day 10: Version 3 created, version 2 becomes inactive and will expire in 45 days ( day 55 ). Day 11: Version 4 created, version 3 becomes inactive and will expire in expire in 45 days ( day 56 ). Attention: now version 1 expires, because VEREXIST says, that only 3 versions are kept, although version 1 "normally" would have expired on day 50 would have expired! Day 55: Version 2 expires by RETEXTRA as mentioned. Day 56: Version 3 expires by RETEXTRA as mentioned. Version 4 never expires!
<!--
* *
* -->
2. case study - original file is deleted
Day 1: Version 1 created Day 5: Version 2 created, version 1 becomes inactive and will expire in 45 days ( day 50 ). Day 10: Version 3 created, version 2 becomes inactive and will expire in 45 days ( day 55 ). Day 11: Version 4 created, version 3 becomes inactive and will expire in expire in 45 days ( day 56 ). Attention: now version 1 expires, because VEREXIST says, that only 3 versions are kept, although version 1 "normally" would have expired on day 50 would have expired! Day 15: original file is deleted! Version 4 becomes inactive and will expire in 62 days ( day 77 ) expire. Attention: now version 2 and version 3 expire, although they "normally" would have expired on day 55 and 56, respectively because VERDEL says that only 1 version is kept 1 version will be kept, if the original the original file has been deleted. Day 77: Version 4, the last version, expires by RETONLY
as mentioned. <!--
Now, ALL are gone with the wind!
All clear? --- If not, then maybe a cognac and a slide rule will help!
-->