If file a file named 'a' is renamed to 'b', there is no way for TSM or any
other application (except perhaps for the application that performed the
rename, but then that depends on the application) to know that 'b' is the
same file as 'a'. It is not a bug in TSM that it doesn't recognize that
file 'b' used to be file 'a'.
If the file is renamed, then the creation date/time becomes the creation
date/time that the file was renamed, and the last access date remains
unchanged. For example, suppose file 'a' has a creation date of 02/10/2002
and a modification date of 02/15/2002. After file 'a' is renamed to 'b',
the creation date is 03/05/2002, but the modification date remains the
same. So the fact that TSM showed the .avb file as having a creation date
later than the modification date is correct, as it is just reflecting the
file system information for that file at the time TSM backed it up.
You can verify this for yourself. On an NTFS file system, find some file
that you can rename, say, junk.txt. Run these commands:
dir junk.txt
dir junk.txt /tc
ren junk.txt test.txt
dir test.txt
dir test.txt /tc
The first dir command will show the modification time for the file; the
second command will show the creation time. After the file is renamed, the
third dir command should show the same modification time as the first dir
command, but the fourth dir command will show the current time as the
creation time; and it will appear to have been created after it was
modified.
As to how to recover the file: if your RETONLY setting is for 365 days,
then unless this rename occurred a year or more ago (which doesn't seem to
be the case), an inactive version of the .exe file should still be
around... though it too may be corrupt.
Regards,
Andy
Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: [EMAIL PROTECTED]
The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
Cory Heikel <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
03/05/2002 08:59
Please respond to "ADSM: Dist Stor Manager"
To: [EMAIL PROTECTED]
cc:
Subject: Re: Urgent question: Version retention
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
