Versions and retention periods
The retention periods and the number of versions of a file to be retained are determined by IBM Storage Protect (formerly TSM) using 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 understands by active and 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 in question at the time of the last backup. The inactive versions are all previous 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 in question at the time of the last backup, i.e. it has been deleted.
Now to the four sizes mentioned:
VEREXIST = N says that a maximum of N backup copies are stored. (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. will be kept. We say up to because the oldest copy always expires immediately expires immediately, regardless of RETEXTRA, if VEREXIST is exceeded. (our value: RETEXTRA = 62) VERDEL = N says that only the N most recent backup copies will continue to be 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 also becomes an inactive version! (our value: VERDEL = 1) RETONLY = N says how many days the most recent backup copy of a file is kept when file is kept if Spectrum Protect has registered that the original the original file on the disk has been deleted. (our value: RETONLY = 62)
The following 2 case studies should clear up the "chaos" somewhat:
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 45 days ( day 56 ). Attention: now version 1 expires, because VEREXIST says that only 3 versions are kept, although version 1 would "normally" only expire on day 50 would have expired! Day 55: Version 2 expires via RETEXTRA as mentioned. Day 56: Version 3 expires via RETEXTRA as mentioned. Version 4 never expires!
-->
2nd 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 45 days ( day 56 ). Attention: now version 1 expires, because VEREXIST says that only 3 versions are kept, although version 1 would "normally" only expire 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 only 1 version will be kept if the original file has been deleted. Day 77: Version 4, the last version, expires RETONLY as mentioned.-->