By "keep versions for 90 days", I assume you mean the RETEXTRA setting. I
think the confusion may come from thinking that this setting indicates how
long to keep backup versions from the time they are created (?). This is
not the case; rather, RETEXTRA indicates how long to keep the backup
version after it goes in inactive. So if the next backup version after the
one created on December 8 was taken, say, January 8, then the 90 day count
for the Dec 8 version starts on Jan 8. Thus it would be eligible for
expiration on April 8 (or thereabouts if I counted 90 days correctly).

The idea is that if you are doing incremental backups on a daily basis,
backing files up only when they have changed, then by setting RETEXTRA to
90 days, you are helping to ensure that users can recover a file up to 90
days after they made a change that they want to undo.

RETEXTRA also works in tandem with VEREXISTS. This means that there is not
necessarily any guarantee that the file will be around for 90 days. For
example, if the file changes every day and VEREXISTS is set to, say, 5,
then on day 6 when the 6th backup is taken, the 1st backup taken on day 1
will be expired regardless of the RETEXTRA setting.

On the other hand, if VEREXISTS is set to 10 but the file changes only a
monthly basis, then you will never have 10 backup versions at a time
because any extra (inactive) versions older than 90 days will expire.

So... if you want to provide a service that will almost always guarantee
that your users can recover files up to 90 days after changing them, you
could set VEREXISTS to 90 (or 91 if you want to "fudge" a day). Then even
if the file changes daily causing your daily backups back it up every day,
you'll have that 90 day restorability.

Other food for thought: sometimes uesrs want multiple backups per day. In
that case, if VEREXISTS is set to 90 and you make, say, 2 backups a day,
then you'll only have 45 day restorability (2 backups per day, VEREXISTS=90
means 45 days to restore the oldest version before it expires). If this
goes on a lot in your shop, consider setting VEREXISTS to NOLIMIT. Then you
can take as many backups as you need, and all the inactve versions will be
around for 90 days after they go inactive.

Regards,

Andy

Andy Raibeck
IBM Tivoli Systems
Tivoli Storage Manager Client Development
e-mail: araibeck AT tivoli DOT com
"The only dumb question is the one that goes unasked."


Patrick Boutilier <boutilpj AT STAFF.EDNET.NS DOT CA>@VM.MARIST.EDU> on 
03/30/2001
06:43:04 AM

Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>

Sent by:  "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>


To:   ADSM-L AT VM.MARIST DOT EDU
cc:
Subject:  Confusion with retention values.



Hello,

I have a Backup Copy group defined as where I keep versions for 90 days and
keep
deleted files for 90 days (at least that what I think it should do).
However I
see files hanging around for more than 90 days when I do some looking. For
instance there is an inactive file called 3744c320.000 that was backed up
on Dec. 08, 2000. This file is older than 90 days so it should be expired.
So
far I have only seen this with Netware servers. Any ideas? Thanks.


ADSM Server = 3.1.2.90




Copy Destination     NETWAREDISK

Frequency  0

Versions Data Exists   9999

Versions Data Deleted   9999

Retain Extra Versions   90

Retain Only Version   90

Copy Mode   Modified

Copy Serialization  Shrstatic