ADSM-L

Re: Backup File Versioning

1997-02-26 20:43:25
Subject: Re: Backup File Versioning
From: Andy Raibeck <araibeck AT VNET.IBM DOT COM>
Date: Wed, 26 Feb 1997 17:43:25 PST
Trevor Foley asks:

>Am I missing something here. I have my backup copygroup set to VERExist=9
>RETExtra=38. According to what I have read here, and my understanding of
>what is in the documentation, at least 3 versions of each file should be
>retained, and all versions backed up in the last 38 days should be
>retained. Is my understanding correct?

>Because what I am seeing on my machine doesn't tie up with that. My ADSM
>server is AIX, ADSM version 2.1.5.12 and the client that I am looking at at
>the moment is WindowsNT, version 2.1.0.6. If I look at all versions of a
>file that I know gets backed up every day (dsmsched.log as an example), I
>only see 3 versions, one active and 2 inactive. These have modification
>dates of the last 3 nights, as I would expect. But what happened to all of
>the other versions of the files that were backed up over the last 38 days?

VEREXIST=9 says to keep a maximum of 9 backup versions. RETEXTRA=38 says
that any extra (i.e. inactive) versions will be kept for up to 38 days.
I say "up to" because the version will be expired based on whichever
criterion is reached first. For example, suppose you create 9 backup versions
over the course of 9 consecutive days. Then on day 10, you create a 10th
backup version. The least recent version will be expired, regardless of the
RETEXTRA value, because the VEREXIST limit was reached. Likewise, if you
create a backup version on day 1 and another backup version on day 2, then
never back the file up again (say it hasn't changed), the original version
created on day 1 will be expired on day 40 (38 days after day 2, which is
when the next backup version was created), regardless of the VEREXIST value
because the RETEXTRA limit was reached.

Example:

day 1: Version 1 created.

day 5: Version 2 created; Version 1 goes inactive, and will be expired 38
       days (day 43).

day 17: Version 3 created; Version 2 goes inactive, and will be expired 38
        days from now (day 55).

day 18: Version 4 created; Version 3 goes inactive, and will be expired 38
        days from now (day 56).

day 19: Version 5 created; Version 4 goes inactive, and will be expired 38
        days from now (day 57).

day 21: Version 6 created; Version 5 goes inactive, and will be expired 38
        days from now (day 59).

day 30: Version 7 created; Version 6 goes inactive, and will be expired 38
        days from now (day 68).

day 31: Verison 8 created; Version 7 goes inactive, and will be expired 38
        days from now (day 69).

day 32: Version 9 created; Version 8 goes inactive, and will be expired 38
        days from now (day 70).

day 33: Version 10 created; Version 9 goes inactive, and will be expired 38
        days from now (day 71); Version 1 is expired because VEREXISTS says
        to keep only 9 versions. Note that Version 1 would otherwise have
        been expired on day 43, as noted above, if it hadn't been "forced"
        by VEREXISTS.

day 55: Version 2 is expired per the RETEXTRA value, as noted above.

day 56: Version 3 is expired per the RETEXTRA value, as noted above.

etc............ (I hope this makes sense)

As to why you are seeing only 3 version on your NT client, I don't know.
Maybe it's getting a different management class?

Andy Raibeck
ADSM Level 2 Support
<Prev in Thread] Current Thread [Next in Thread>