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.
-->