ADSM-L

Re: Confusion with retention values.

2001-03-30 13:40:59
Subject: Re: Confusion with retention values.
From: Patrick Boutilier <boutilpj AT STAFF.EDNET.NS DOT CA>
Date: Fri, 30 Mar 2001 14:41:32 -0400
Makes sense. I did a query on the BACKUPS table and that shows the deactivate
date. Too bad the clients didn't show the deactivate date. :-)

I always assumed that Retain Extra Versions = 90
 meant that anything that was backed up 90 days ago would be deleted, not 90
days from the deactivation date.

This way you might be able to restore something from more than 90 days ago.
Makes it harder to tell your clients exactly how back you can restore from. :-)


STATE             LL_NAME     BACKUP_DATE        DEACTIVATE_DATE
------------------     ------------------     ------------------
ACTIVE_VERSION     36E54BF0.000  2001-03-20
ACTIVE_VERSION     36E54BF0.000  2001-03-20
INACTIVE_VERSION   36E54BF0.000  2000-12-08   2001-02-17
INACTIVE_VERSION   36E54BF0.000  2001-02-17   2001-03-20



Quoting Andy Raibeck <Andrew_Raibeck AT TIVOLI DOT COM>:

> 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
>



Staff Sig...