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/[EMAIL PROTECTED] Internet e-mail: [EMAIL PROTECTED] (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. "[EMAIL PROTECTED]" <kurt.beyers Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 03/27/2003 01:04 Please respond to "ADSM: Dist Stor Manager" To: [EMAIL PROTECTED] 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" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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/[EMAIL PROTECTED] > Internet e-mail: [EMAIL PROTECTED] (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. > > > > > "[EMAIL PROTECTED]" <kurt.beyers > Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> > 03/26/2003 07:49 > Please respond to "ADSM: Dist Stor Manager" > > > To: [EMAIL PROTECTED] > 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