Hi Kurt,
You are welcome. Sorry if that post is a bit convoluted. I'll try to
explain some more, so please bear with me.
- VEREXISTS is the *maximum* number of versions to keep in inventory while
the file exists on the client machine.
- VERDELETED is the *maximum* number of versions to keep in inventory if
the file no longer exists on the client machine. Note: "no longer exists"
applies if the file is deleted, moved, or renamed, or if you modify your
TSM include/exclude list to exclude the file. Any of these conditions will
make the file appear, from TSM's perspective, to have been deleted.
- As long as the file exists on your client machine (and you don't delete,
move, rename, or exclude it), the latest backup version is the "active"
version. The active versions comprise a current "image" of the data on the
client machine (with "current" being as of the last TSM backup). So if you
backed up your machine last night at 1:00 AM, then the active backup
versions reflect the state of the data on your machine as of 1:00 AM last
night. Note that for each file, there can be one and only one active
backup version. Active versions are not subject to expiration. So if you
back the file up once and the file never changes, TSM will keep the active
version indefinitely (assuming you don't delete, rename, move, or exclude
it).
- When TSM makes a new backup of a file, this new backup version becomes
the active version, and the previous active version is deactivated (made
"inactive"). You can have zero, one, or multiple inactive versions. The
maximum number of inactive versions is VEREXISTS - 1. So if VEREXISTS is
1, then you get only the active version. If VEREXISTS is 5, then you get
one active version and a maximum of 4 inactive versions.
- RETEXTRA defines the maximum number of days to keep *inactive* versions.
The most frequent area of confusion is when the clock starts ticking: It
starts ticking as of the time the version became inactive, NOT from the
time the version was created. For example, suppose RETEXTRA is 5 (and
VEREXISTS is 2 or more). On day 1 you back up a file. That backup version
is the active version. Then on day 7, the file changes, and TSM backs the
file up again. The new backup version is the active version, and the
version you created on day 1 is now inactive. It is at this point that the
RETEXTRA setting comes into play: In 5 days (day 12), this inactive
version will be deleted from TSM's inventory (when inventory expiration
runs). Another way of looking at this: RETEXTRA 5 gives you 5 days in
which to recover the previous version of the file.
- VERDELETED works the same way as VEREXISTS, but only comes into play
when TSM detects (during the next incremental backup of your machine) that
the file no longer exists. Many users probably set VERDELETED and
VEREXISTS to the same value, but this setting does give you an extra
degree of flexibility, should you need it. For example, you might set up a
policy that says to keep up to 5 versions while the file exists, but only
2 versions if it is deleted. So if a file has 5 backup versions (1 active,
4 inactive), and TSM detects that the file has been deleted, then it will
(1) make the active version inactive, and (2) get rid of the 3 oldest
backup versions, leaving you with 2 inactive versions. Remember earlier
when I said that the active versions comprise an "image" of the data on
the client machine, so once a file is deleted, TSM makes the active
version inactive to maintain this "image". NOTE: I am using the word
"image" loosely; it has no relationship to the TSM BACKUP IMAGE function.
- Like VERDELETED, RETONLY comes into play when TSM detects that the file
no longer exists. As time goes by, older backup versions will expire from
TSM 's inventory based on the VERDELETED and RETEXTRA settings. RETONLY
tells TSM how many days to keep the final remaining version (from the time
it was made inactive, just like RETEXTRA). So suppose your RETEXTRA
setting is 30 days, but you want to give your users a longer opportunity
to bring a file back from the dead. In this case, you could set RETONLY
to, say, 60. This will give users up to 60 days to restore the last
remaining backup version (which also happens to be the most recent
version), even if all the older versions have been deleted from TSM's
inventory. Like VERDELETED, RETONLY just gives you an extra bit of
flexibility, but if you don't need it, then just set it to the same as
RETEXTRA.
- Note that I said RETEXTRA is the *maximum* number of days to keep
inactive versions, and VEREXISTS (and VERDELETED) is the *maximum* number
of versions to keep. Inactive backup versions are subject to deletion from
TSM's inventory when *either* of these criteria are met. For example,
suppose RETEXTRA is 30 and VEREXISTS is 5. If you perform manual backup of
a file 5 times in quick succession, then you've reached the maximum number
of versions. If you back the file up again (a 6th time), then the oldest
backup version goes away, even though none of the backup versions is older
than a few minutes. On the other hand, suppose you back a file up on day
1. The file changes again (and is subsequently backed up) on day 8, but
thereafter never changes again. This causes the original backup version
from day 1 to become inactive. In this case, you have not reached or
exceeded VEREXISTS (5 versions); but on day 38 (day 8 + RETEXTRA value of
30 days) the original backup version goes away.
- My earlier examples of RETEXTRA 30 and VEREXISTS 5 hopefully helped
explain the concepts, but are not practical, at least not unless you have
data that you know would fit such a usage pattern. Otherwise it is
probably safest to assume that all data could change daily, so there is no
point in having a RETEXTRA value that is larger than VEREXISTS.
To conclude: I think that the explanation is far more complex than the
actual concept. Conceptually, I like to think of these copygroup settings
as simply affording your users up to 'n' number of days to recover a file.
And that is the approach that you should take when defining these
settings. Rather than asking your users, "how many inactive versions do
you want?", or "how long do you want to keep the versions if the file is
deleted?", it is easier to ask, "How far back to you need to be able to
recover your data?" This would make the RETEXTRA/RETONLY settings the real
criteria to manage by. For example, suppose your users need to be able to
recover up to a month ago (let's say 31 days). Then you could set up your
copygroup like this:
VEREXISTS=31
VERDELETED=31
RETEXTRA=31
RETONLY=31
The above assumes that backup runs once a day, and allows for a file to
change on a daily basis. This is probably fine for most data. However,
some users might back up more than once a day. In this case,
VEREXISTS/VERDELETED would not give you that 31 day restore capability,
since versions would be deleted when the RETEXTRA limit is reached. So the
following might be better:
VEREXISTS=NOLIMIT
VERDELETED=NOLIMIT
RETEXTRA=31
RETONLY=31
This will allow users to make as many backups as they want, and they can
always recover any of them for up to 31 days. Depending on how much data
is backed up more than once a day, this could be more costly. If you
charge your users for the service on a usage basis, this will help keep
things practical. :-)
Of course, you can have multiple management classes with different
copygroup settings. This gives you the flexibility to manage different
data to different criteria, as needed.
Hope this helps,
Andy
Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.eyebm DOT com (change eye to i to reply)
The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
"kurt.beyers AT pandora DOT be" <kurt.beyers
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
03/27/2003 01:04
Please respond to "ADSM: Dist Stor Manager"
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Re: definition copy group
Andy,
Thanks for the answer and the link to your previous post. Most of the
doubts I still had are clarified there. I only have to read it a few more
times I think
Kurt
----- Original Message -----
From: "Andrew Raibeck" <storman AT US.IBM DOT COM>
To: <ADSM-L AT VM.MARIST DOT EDU>
Sent: Wednesday, March 26, 2003 3:59 PM
Subject: Re: definition copy group
> "Versions Data Deleted" applies only after you delete the file from the
> client file system. It has no affect as long as the file still exists.
>
> By way of additional answer, check out an older post containing a series
> of notes related to these copygroup settings,
> http://msgs.adsm.org/cgi-bin/get/adsm0103/983.html. Best read from the
> bottom-up.
>
> Regards,
>
> Andy
>
> Andy Raibeck
> IBM Software Group
> Tivoli Storage Manager Client Development
> Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
> Internet e-mail: storman AT us.eyebm DOT com (change eye to i to reply)
>
> The only dumb question is the one that goes unasked.
> The command line is your friend.
> "Good enough" is the enemy of excellence.
>
>
>
>
> "kurt.beyers AT pandora DOT be" <kurt.beyers
> Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> 03/26/2003 07:49
> Please respond to "ADSM: Dist Stor Manager"
>
>
> To: ADSM-L AT VM.MARIST DOT EDU
> cc:
> Subject: definition copy group
>
>
>
> Hi,
>
> I'm sorry for the previous post. I've pressed the send button a bit too
> early.
>
> Suppose I've got the following copy group defined in a management class:
>
> Versions Data Exists: 5
> Versions Data Deleted: 2
> Remain Extra Versions: 30
> Remain Only Version: 60
>
> I take a backup of a file A which changes 5 times, so I'll have 5
> incremental versions (A1, A2, A3, A4, A5 with A5 being the active
> version).
>
> Suppose now that the file A don't change any more (A5 is the current
> active version) but remains on the server. 30 days after the backup of
the
> version A1, it will expire. The same for the versions A2 and A3.
>
> Will the version A4 also expire 30 days after the backup of itand will I
> only have the version A5 on tape? Or does the expiration of extra
versions
> halts when the number of versions gets equal to the number of 'versions
> data deleted'?
>
> According to the reference guide, the version A4 will expire also 30
days
> after the backup of it.
>
> Thanks for the assistance,
>
> Kurt
|
