Highlighted
ottov
1 Nickel

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

0 Kudos
5 Replies
coganb
3 Argentium

Re: Tape retention other than saveset retention after cloning

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
1 Nickel

Re: Tape retention other than saveset retention after cloning

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:

taperet.jpg

I wonder if we are OK with this or if this a bug we need to address.

0 Kudos
ottov
1 Nickel

Re: Tape retention other than saveset retention after cloning

This is result from:

mminfo -q "volume=<volume name>" -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

0 Kudos
coganb
3 Argentium

Re: Tape retention other than saveset retention after cloning

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

ottov
1 Nickel

Re: Tape retention other than saveset retention after cloning

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.

0 Kudos