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 >>> [EMAIL PROTECTED] 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 >>> [EMAIL PROTECTED] 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 -----Original Message----- From: Cory Heikel [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 05, 2002 9:04 AM To: [EMAIL PROTECTED] Subject: Urgent question: Version retention We were hit by the klez virus over the weekend. In trying to restore some files from pre infected state I found what appears to be a fatal flaw in the way I have versioning set up (or a "feature" in tsm). We are running win/nt 4.0 sp6a and tsm 4.2.1 client, the server is on aix and also 4.2.1. These are the parms I am using. Versions Data Exists NOLIMIT Versions Data Deleted 2 Retain Extra Versions 33 Retain Only Version 365 Copy Mode MODIFIED Copy Serialization SHRSTATIC Copy Frequency 0 The idea was to be able to keep up to the last 33 days of changes to any given file. What happened is this - when our virus program detected the virus it renamed the files from .exe to .avb. Tivoli, it appears, did not make a distinction between the files and just backed up the new .avb file as a newer version of the .exe file. Since the .exe had not been changed since the end of November, the only good backup of that file was dropped because it was over 33 days old. I believe that this is what is occurring because when I look at the file details for these files (on the restore screen) I see this: Name Size Modified Created Backed up hqd.avb 98 kb 29-nov-01 02-mar-02 03-mar-02 Note that the create date is more than 3 months later than the modified date. My questions are: 1. does this sound like a bug in tsm? 2. is it more likely a problem in the way the anti-virus software is renaming the file? 3. Is there any was to tell tivoli to keep a certain minimum number of versions, something along the lines of a RETAIN MINIMUM VERSIONS so that both high and low water marks and be kept for any given copygroup? Your help is greatly appreciated. Cory Heikel Sr. Systems engineer Milton S. Hershey Medical Center (717) 531-7972 "MMS <health-first.org>" made the following annotations on 03/05/02 12:19:07 ------------------------------------------------------------------------------ This message is for the named person's use only. It may contain confidential, proprietary, or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it, and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Health First reserves the right to monitor all e-mail communications through its networks. Any views or opinions expressed in this message are solely those of the individual sender, except (1) where the message states such views or opinions are on behalf of a particular entity; and (2) the sender is authorized by the entity to give such views or opinions. ==============================================================================
