I always thought both versions and retention criteria are evaluated when
expiration is run. Never tested it until recently. The results were more
than strange:
1. Due to some business reasons it was requested all current versions to
be held (i.e. expiration had to be disabled temporarely)
2. It took longer than expected and TSM server accumulated more versions
than specified by verexist copygroup setting
3. Request for restore of data more than N versions back was submitted and
failed. Further investigation showed data *is* in the server - queries
against 'backups' and 'contents' tables show the files. However the client
*cannot* see those "too old" versions. Increase of vere-setting did not
help.
Your explanation does not explain all the aspects of seen behavior but I
assume the latter is a bug. Upon my investigation completion a PMR will be
opened.

Zlatko Krastev
IT Consultant






Richard Sims <rbs AT BU DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
16.01.2003 14:25
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: Quick expiration question


>Just a quickie. When an inremental backup runs, some files get expired.
>Does this mean that they are 'marked' for expiration, but only get
deleted
>from the database when the Expire Inventory job is run?

File expiration candidates processing based upon versions (number of same
file)
is performed during client Backups (in contrast to time-based retention
rules,
which are processed during a later, separate Expiration).

  Richard Sims, BU