This blog will try to explain VEREXIST, VERDELETED, RETEXTRA and RETONLY options. This will not attempt to explain how to find out those values for a random file backed up on your TSM though.
First question: do you use queries to look up your backups? Yes, command line I mean. For advanced things it is a must. Here is a simple example:
select * from
backups where node_name='MAILSERVER'
NODE_NAME: MAILSERVER
FILESPACE_NAME: MAILSERVER.DOMDBS
FILESPACE_ID: 1
STATE: INACTIVE_VERSION
TYPE: FILE
HL_NAME: \MAIL\
LL_NAME: JOHNSMITH.NSF.DATA
OBJECT_ID: 597594810
BACKUP_DATE: 2013-06-12 20:49:57.000000
DEACTIVATE_DATE: 2013-06-13
20:51:48.000000
OWNER:
CLASS_NAME: DEFAULT
[many more items follows]
You can investigate what is there, but what is interesting now is the “STATE” information. As you know, the TSM can keep multiple versions of one file. A backed up file has one or no active version and might have multiple inactive versions. Unique identification here is not HL_NAME+LL_NAME (all versions of the file has the same LL and HL_NAME ), but OBJECT_ID. From above you can say that this version was backed up on June 12th, and new version of file was backed up a day later and so status of this version changed to inactive
So this was short but needed introduction and now the main part:
Two processes are important:
A) Backup process - it applies versioning policy every time you are backuping/archiving:
| If source file exists | If source file no more exists | |
| Previous active version |
Changed to inactive
|
Changed to inactive*
|
| Inactive versions (including newly de-activated one) |
Their number are reduced*** to $VEREXIST-1** (if needed)
|
Their number are reduced*** to $VERDELETED (if needed)
|
* Under some circumstances the file will remain active (while the source file no more exists on client server) and may remain so “forever”. It seems that it might relate to the type of backup incremental vs. selective. (But this issue/behaviour out of scope of this blog.)
** because active version is also counted
*** the 'reduction' is done via setting 'DEACTIVATE_DATE: 1900-01-01 00:00:00.000000', the version of file itself is deleted by next expiration process
B) Expiration process - As you probably know, expiration is a separate process running once per day or so....
Important: This deals with inactive files only!
If source file exists
|
If source file no more exists
|
|
| The latest inactive version of non-existent file |
Not applicable
|
expires after $RETONLY days after time when status was changed
to INACTIVE
|
| Interactive versions in general (save the one reffered to in a row above) |
expires after $RETEXTRA days after time when status was changed
to to INACTIVE
|
expires after $RETEXTRA days after time when status was changed
to INACTIVE
|
Well I wrote "expires" but it should be read "is deleted".
And this is all, I hope it helped you and there are no factual errors (save some simplifications).
