Unsolved
This post is more than 5 years old
63 Posts
0
1188
Tape retention other than saveset retention after cloning
Hi I have this strange problem
When cloning data to tape we don't get the same retention on the tape as on savesets on the tape. The savesets are with date in 2015 while the tape is only 2013.
While the tape is in the drive in the library and is written to get information Expiration: 19.12.13
It does not fit with our retentiontime.
When I check the tape volume in the media dashboard, the Expiration date is correct, ie it agrees with retentiontime 3 years ahead of time.
After the cloning to check the retention of tape we put in the drive again and all the saveset are january 2015 but tape volume dec. 2013.
Does anyone have any Idea why this might be?
I thought the tape should reflect the saveset retention.
Best regards Otto
coganb
736 Posts
1
January 31st, 2012 06:00
Hi Otto,
That does sound very strange. The retention date on the volume (volretent field in the media database) should be equal to the latest saveset-clone-instance retention date on that volume (clretent field). You should check if that is the case by looking in the media database:
mminfo -q "volume=[volume name here]" -r "ssid, client, name,cloneid, ssflags, clflags, ssretent, clretent, volretent"
Check what the saveset with the latest clretent is. This should match the volretent.
-Bobby
ottov
63 Posts
0
February 2nd, 2012 00:00
This how it looks and that is what we want:
~]# mminfo -av -qvolume=B20169 -rvolretent
01/06/2015
~]# mminfo -av -qvolume=B20169 -rssid,ssretent,ssbrowse
ssid retent browse
336045869 01/06/2015 01/06/2015
1560771842 01/06/2015 01/06/2015
1359445251 01/06/2015 01/06/2015
1543994626 01/06/2015 01/06/2015
1342668035 01/06/2015 01/06/2015
1476885762 01/06/2015 01/06/2015
1325890819 01/06/2015 01/06/2015
1158118660 01/06/2015 01/06/2015
1309113603 01/06/2015 01/06/2015
268937014 01/06/2015 01/06/2015
369600293 01/06/2015 01/06/2015
285714224 01/06/2015 01/06/2015
386377509 01/06/2015 01/06/2015
In the GUI however it looks like this:
I wonder if we are OK with this or if this a bug we need to address.
ottov
63 Posts
0
February 2nd, 2012 01:00
This is result from:
mminfo -q "volume= " -r "ssid, cloneid, ssflags, clflags, ssretent, clretent, volretent"
ssid clone id ssflags clflg retent clretent expires
336045869 1327307048 vF 01/06/2015 01/06/2015 01/06/2015
1560771842 1327318928 vF 01/06/2015 01/06/2015 01/06/2015
1359445251 1327307048 vF 01/06/2015 01/06/2015 01/06/2015
1543994626 1327309208 vF 01/06/2015 01/06/2015 01/06/2015
1342668035 1327307048 vF 01/06/2015 01/06/2015 01/06/2015
1476885762 1327309208 vF 01/06/2015 01/06/2015 01/06/2015
1325890819 1327307048 vF 01/06/2015 01/06/2015 01/06/2015
1158118660 1327307048 vF 01/06/2015 01/06/2015 01/06/2015
1309113603 1327307048 vF 01/06/2015 01/06/2015 01/06/2015
268937014 1327307048 vF 01/06/2015 01/06/2015 01/06/2015
369600293 1327307048 vF 01/06/2015 01/06/2015 01/06/2015
ottov
63 Posts
0
February 2nd, 2012 02:00
Hi Bobby
just what I thought. It could be a bug.
There is a plan for an 7.6.3 upgrade soon so we will see after that. I incorrectly set this as a 7.6.2. we in fact have 7.6.1.
Thank you very much for the help on this I really appreciate it.
Otto.
coganb
736 Posts
1
February 2nd, 2012 02:00
Hi Otto,
The retention dates are all correct where it counts most which is in the media database. That this is not correctly reflected in the NMC looks like a bug to me. It shouldn't have any impact on the recycling of your data, but you should probably open a Service Request with support to get it checked out as it's not behaving as it should.
-Bobby