ADSM-L

Re: Urgent question: Version retention

2002-03-05 12:09:06
Subject: Re: Urgent question: Version retention
From: David Longo <David.Longo AT HEALTH-FIRST DOT ORG>
Date: Tue, 5 Mar 2002 12:05:57 -0500
I have a few answers.

1.  Looking at expiration and seeing that it expired "1 backup object" does
not necessarily mean it expired 1 file on your client node.  The way TSM
aggregates files etc. (I won't go into details, mainly as I don't know the
fine details), makes it an abstraction as to the number of objects expired
and the number of files on your client expired.

2.  It you have a file test.txt and it has been backed up, then you rename
the file test.bat, then that is a new file to backup and the old file doesn't
exist anymore as designed by TSM functionality.  The old one should stay
inactive for the period specified by your management class.  TSM doesn't
"know" that you renamed it.  As far as it can determine you deleted the old
file and created a new one.

David Longo

>>> CHEIKEL AT PSU DOT EDU 03/05/02 10:59AM >>>
Agreed, my concern is why the retain only did not kick in at the time the files 
was renamed to .avb. Is tsm really not recognizing a change in the file even 
though its' type changed? I have displayed active and inactive versions for 
these files and it is as if the .exe version never existed. I have also looked 
at the expire inventory and it shows only 1 file being expired for the entire 
server. I know of at least 18 on this particular server that are in the same 
situation. So it doesn't seem to have expired the .exe version of the files.

Cory

>>> DMalbrough AT TTIINC DOT COM 03/05/02 10:47AM >>>
It seems to me that this was a very rare situation! As you stated, TSM would
not have changed the extension on the file from .exe to .avb, that was the
anti-virus software or virus itself. Since this file did not change in 33
days this was the only file, which was **ACTIVE** since Nov. 29th, 2001.
Thirty-three days passed by WITHOUT the file changing (Dec 31st, 2001).

So, if this file is changed any point after Dec 31st, it will become
INACTIVE & be flagged for expiration after the next incremental backup. If
expiration has already been run (typically it has if it runs daily) the now
INACTIVE copy hqb.exe will drop off and this file (corrupted) hqb.avb will
be ACTIVE for 33 days (beginning March 2nd,2002) until it is changed!


The only thing that could've gotten you out of this situation was a longer
"Retain Extra Versions"!

Only my thoughts!!!!!

Regards,

Demetrius Malbrough
UNIX/TSM Administrator