i can confirm that described problem. Wen ran into that condition yesterday with Networker Version 7.5.2. The intention was to keep cloned savesets longer available than original ssid´s.
I have done a quick test here using a longer retention period for the clone pool and this worked as I would expect - i.e. the clone retention is longer than the retention of the original.
It would appear to me that your mminfo command is incorrect which is leading you to incorrect conclusions about this. Your mminfo command is looking for the 'ssretent' rather than the 'clretent'. The 'ssretent' will always be the latest retention date for all instances of this saveset. The clretent corresponds to the retention date of the actual saveset instance - the Primary and Clone are two different saveset instances and will have two different clretent values which correspond to when each instance will expire. The ssretent will be the same for both and will correspond to the later of the two clretent dates.
Therefore, the volretent is the latest clretent date of all savesets on that volume (and not necessarily the latest ssretent date as you might expect).
I wrote a KB article on this a while back which might clarify this for you.
Bobby I'm talking about version 7.6.1 where browse time is specifically selectable. This was never possible in the past. As I discovered, code
changes automatically both time to the longer time as no new index database was created to keep clone independently in den Index DB.
Yes, this may be true for the retention time. You may right with the mminfo query which is not correct, but if you look in the volume section in the nmc
after I did apply the clone schedule with 10 yars ret/bwrowse time the Volume Expiration time of both volumes (original and cloned) was changed to
the longer of both. Means that primary is not recyceling.
Anyway all mentioned article mentioned only the point about retention time. This time was adaptable since quite long time in the pool retention.
But what hapens with the prowse time.
Still my observations where, that it doesn't work, as Volume expiration Time was changed on the original ATF volume and as well on the cloned with 10 years Browse/retention.
So I did in the mean time some more tests and yes I can confirm it works correct. Problem was that following mminfo query and the fact that the UI is showing the wrong infos, I thought it will be wrong:
Use Case:
========
1. Original Save-Set save-set browse/retent policy 1 Min.
2. Scheduled Clone (New 7.6.1) browse/retent 1 Year
3. Save was done on the 12.10.2010 (tt.mm.yyyy)
After 1 x Full Save (no Clone)
>mminfo -v -a -r volume(2),ssbrowse,ssretent,volretent,copies,ssid,cloneid,clretent,clonetime,name,volume,pool
shows
before cloning
browse,retent,expires...clretent
12.10.2010,12.10.2010,12.10.2010,12.10.2010
after scheduled clone with 1 Year ret/browse the original saveset showed:
12.10.2011,12.10.2011,12.10.2010
Notice that the retention time on the original saveset was changed from 12.10.2010 to 12.10.2011.
This is shown only in the mminfo query, it's in my opinion an error, this should be 12.10.2010.
This is why I thought it's wrong.
After running nsrim or nsrim -X to expire the original Save-Set with the "wrong" retention time, save set was deleted in WISS DB and
looks now ok. Saveset was deleted and Clone ret/browse looks ok. What's about mminfo output ? Case ? it's wrong or should be like that.
This mminfo output should be like that. The 'ssretent' date is the latest retention date for all clone instances of this saveset (original and all clone copies). When you clone a saveset and the clone has a later retention than the original, then the 'ssretent' of both will be pushed out to the later date. As you observed, this will not affect the actual retention behaviour of the original saveset-instance.
The important thing to remember is that the 'clretent' date corresponds to the retention of the saveset-instance that you are interested in. This is the date that will not change after cloning a saveset.
franknitsch
15 Posts
0
October 5th, 2010 00:00
Hello Juerg,
i can confirm that described problem. Wen ran into that condition yesterday with Networker Version 7.5.2. The intention was to keep cloned savesets longer available than original ssid´s.
Regards
Frank
MarkusSchneebeli
11 Posts
0
October 5th, 2010 04:00
Yes Frank, this was absolutely normal as Networker brevious 7.6.1 didn't have any possibility to change the browse time. But now
with 7.6.1, new funtionality of scheduled clone was added and there changing of browse and retention time is selectable in the UI.
This should be independently of the original savesets.
The Point is here, that they implemented this new functionality wronger then wrong.
But it seams that development in india does not understand what people in western country needs.
So may be with Version 19 this might come.
coganb
736 Posts
0
October 5th, 2010 06:00
Hi Juerg,
I have done a quick test here using a longer retention period for the clone pool and this worked as I would expect - i.e. the clone retention is longer than the retention of the original.
It would appear to me that your mminfo command is incorrect which is leading you to incorrect conclusions about this. Your mminfo command is looking for the 'ssretent' rather than the 'clretent'. The 'ssretent' will always be the latest retention date for all instances of this saveset. The clretent corresponds to the retention date of the actual saveset instance - the Primary and Clone are two different saveset instances and will have two different clretent values which correspond to when each instance will expire. The ssretent will be the same for both and will correspond to the later of the two clretent dates.
Therefore, the volretent is the latest clretent date of all savesets on that volume (and not necessarily the latest ssretent date as you might expect).
I wrote a KB article on this a while back which might clarify this for you.
http://solutions.emc.com/EMCSolutionView.asp?id=esg100921&usertype=C
Let me know if this clears things up or if I've got the wrong end of the stick on what you're reporting here.
thanks,
-Bobby
MarkusSchneebeli
11 Posts
0
October 6th, 2010 01:00
Bobby I'm talking about version 7.6.1 where browse time is specifically selectable. This was never possible in the past. As I discovered, code
changes automatically both time to the longer time as no new index database was created to keep clone independently in den Index DB.
Yes, this may be true for the retention time. You may right with the mminfo query which is not correct, but if you look in the volume section in the nmc
after I did apply the clone schedule with 10 yars ret/bwrowse time the Volume Expiration time of both volumes (original and cloned) was changed to
the longer of both. Means that primary is not recyceling.
Anyway all mentioned article mentioned only the point about retention time. This time was adaptable since quite long time in the pool retention.
But what hapens with the prowse time.
Still my observations where, that it doesn't work, as Volume expiration Time was changed on the original ATF volume and as well on the cloned with 10 years Browse/retention.
I will do once again some research
coganb
736 Posts
0
October 8th, 2010 07:00
Hi Juerg,
How is the testing going? Is this working as you would expect/wish or do you think there is something we in EMC need to investigate?
thanks,
-Bobby
MarkusSchneebeli
11 Posts
0
October 12th, 2010 09:00
Hallo Boby
So I did in the mean time some more tests and yes I can confirm it works correct. Problem was that following mminfo query and the fact that the UI is showing the wrong infos, I thought it will be wrong:
Use Case:
========
1. Original Save-Set save-set browse/retent policy 1 Min.
2. Scheduled Clone (New 7.6.1) browse/retent 1 Year
3. Save was done on the 12.10.2010 (tt.mm.yyyy)
After 1 x Full Save (no Clone)
>mminfo -v -a -r volume(2),ssbrowse,ssretent,volretent,copies,ssid,cloneid,clretent,clonetime,name,volume,pool
shows
before cloning
browse,retent,expires...clretent
12.10.2010,12.10.2010,12.10.2010,12.10.2010
after scheduled clone with 1 Year ret/browse the original saveset showed:
12.10.2011,12.10.2011,12.10.2010
Notice that the retention time on the original saveset was changed from 12.10.2010 to 12.10.2011.
This is shown only in the mminfo query, it's in my opinion an error, this should be 12.10.2010.
This is why I thought it's wrong.
After running nsrim or nsrim -X to expire the original Save-Set with the "wrong" retention time, save set was deleted in WISS DB and
looks now ok. Saveset was deleted and Clone ret/browse looks ok. What's about mminfo output ? Case ? it's wrong or should be like that.
regards juerg
coganb
736 Posts
0
October 13th, 2010 00:00
Hi Juerg,
This mminfo output should be like that. The 'ssretent' date is the latest retention date for all clone instances of this saveset (original and all clone copies). When you clone a saveset and the clone has a later retention than the original, then the 'ssretent' of both will be pushed out to the later date. As you observed, this will not affect the actual retention behaviour of the original saveset-instance.
The important thing to remember is that the 'clretent' date corresponds to the retention of the saveset-instance that you are interested in. This is the date that will not change after cloning a saveset.
-Bobby