ADSM-L

Re: Data Retention - Test results

2001-11-16 19:19:22
Subject: Re: Data Retention - Test results
From: Zlatko Krastev/ACIT <acit AT ATTGLOBAL DOT NET>
Date: Sat, 17 Nov 2001 02:17:49 +0200
Hello all,

I got the result and am presenting it to your attention. It is quite
strange from logical point of view but can be explained.
The test environment - TSM server v4.1.4.1 on AIX 4.3.3ML6 and TSM Client
(if it matters) 3.7.2 on OS/2 Warp 4 (UK) Fixpack XRUM009.
So again:
1. A management class was defined with backup copy group having verexist=2
verdeleted=5 retextra=60 and retonly=1.
2. File was backed up (incremental) five times after creation and each
content change. The content of each version was "version N" with N
representing sequence number from 1 to 5.
3. Before any inventory expiration the file was deleted and successfully
expired.
4. Expiration was performed with five inactive versions and after it only
two versions remained !?!
! --> So instead of verdeleted min(verexist,verdeleted) is assumed !
5. After more than one day passed inventory expiration started by schedule.

! --> One file left.
!!! --> And this was not the last version but version 4 !!!
6. Inventory expiration was started again (manually).
! --> The file remained ! TSM remembers somehow that this is not the last
version and used retextra instead of retonly !!
7. copy group was changed with retextra=1 and activated. After inventory
expiration the last kept (but not historically last) version was gone.
THE END.

I did not wait a whole day to pass in step 6. So if the retonly (one day)
timer started ticking since the version become from one-before-last to last
the behavior  can be explained. The deactivate_date filed in backups table
was pointing 2001-11-14. So if this field had to be taken into
consideration the behavior is not logical.
The most important issue is that the version before the last remained
longer than the last one. And if someone restores it he/she has to be
notified on this !
A suggestion to the developers for easy resolution of the problem: do the
same as used in step 4  - for expiration of LAST version use
max(retextra,retonly) instead of retonly. Or just perform boundary check
for 'create copygroup' and 'update copygroup' to ensure ((verexist >=
verdeleted) and (retextra <= retonly)). And do not forget to put this into
docs/readme.


Zlatko Krastev
IT Consultant



---------------------- Forwarded by Zlatko Krastev/ACIT on 16.11.2001 22:14
---------------------------
---------------------------
Zlatko Krastev/ACIT AT attglobal DOT net>
Zlatko Krastev/ACIT AT attglobal DOT net>
14.11.2001 04:02
Sent by:        Zlatko Krastev/ACIT<acit AT attglobal DOT net>
To:     "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
cc:

Subject:        RE: Data Retention

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.
<Prev in Thread] Current Thread [Next in Thread>
  • Re: Data Retention - Test results, Zlatko Krastev/ACIT <=