ADSM-L

Backup column, deactivate_date

2002-09-13 12:44:00
Subject: Backup column, deactivate_date
From: Nathan King <nking AT SATX.RR DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 13 Sep 2002 11:16:48 -0500
I'm trying to understand exactly how the deactivate_date column works in
the backups table.

My understanding is that the deactivate_date within the backups table is
the date upon which a file/object became inactive. If I compare the
deactivate_date with the current policy settings, I should be able to
determine when the file will expire provided ofcourse that it does not
roll off due to exceeding the ver exists or ver deleted.

For example if a file has a deactivate date of 2002-09-13 xxxxxxxx and
my retextra and retonly are both set to 10days and I do not exceed the
no. of versions described in the version exists or ver deleted then the
file should expire on 2002-09-23. Right? Correct me if I'm wrong here.

I also used to remember querying the backups table and I would find
files that were both in a state of inactive, but their deactivate_date
was blank. (You should always see that files in an active state have a
blank deactivate_date). I believed that this was because the file had
exceeded the no. of versions and it was therefore marked for expiration.
Once expiration ran if I then queried the table again, the file no
longer appeared.

I revisited this theory again this week and have come across something I
cannot logically explain. I created a file, backed it up. Modified it
and backed it up again repeatedly until I had exceeded the no. of
versions set in the verexists attribute of the copy group. I actually
backed up five times when my verexists was set to 3 (so I had two extra
versions that should be marked for expiration)

When I queried the backups table, as I expected I found two versions
over and above the no. of versions prescribed in the copy group. That's
expected. I wouldn't expect them to disappear until after I had run
expiration. Indeed after I ran expiration they did disappear.

What was peculiar was that instead of the deactivation_date being blank
they were both set to a deactivation_date of 2002-07-24 19:31:54

Why the 24th July 2002? What's the significance of this date?

I've tried this a couple of times this week. On each occasion the 24th
July date keeps coming back as a deactivation_date. Anyone any ideas?

TSM 5.1.1.4 on Win2k.

Thanks,

Nathan

<Prev in Thread] Current Thread [Next in Thread>
  • Backup column, deactivate_date, Nathan King <=