Skip to main content
Start a Conversation

Unsolved

This post is more than 5 years old

DavidHampson

1.1K Posts

8548

June 5th, 2009 09:00

Savesets not expiring - the retention time is invalid

Here is another strange one - I have one client which has a month browse/retention which has savesets that go back to February that have not expired - no dependency here and generally they are the only saveset on the tapes meaning they are holding up tape reuse - here is some mminfo data:

mminfo -q "client=s-cpp-cmfe01.net1.cec.eu.int,name=C:\\" -ot -r volume,savetime,ssretent,level,clretent,ssflags
...2B1517 02/02/09 03/02/09 full 03/02/09 vF
2B1538 02/03/09 03/03/09 full 03/03/09 vF
2B1541 02/03/09 03/03/09 full 03/03/09 vF
2B1535 02/04/09 03/06/09 full 03/04/09 vrEF
2B1624 02/05/09 03/06/09 full 03/05/09 vrEF
2B1587 02/06/09 03/07/09 full 03/06/09 vrEF
2B1571 02/06/09 03/07/09 full 03/06/09 CvrEF
2B1571 02/06/09 03/07/09 full 03/06/09 CvrEF
2B0011 02/07/09 03/08/09 full 03/07/09 vrF
2B0956 02/07/09 03/08/09 full 03/07/09 vrF

A93674 02/07/09 03/08/09 full 03/08/09 vrF

2B0257 02/08/09 03/09/09 full 03/08/09 vrF
A93582 02/08/09 03/09/09 full 03/09/09 vrF
2B0210 02/09/09 03/11/09 full 03/09/09 vrF
A92929 02/09/09 03/11/09 full 03/11/09 vrF
2B0202 02/09/09 03/11/09 full 03/09/09 vrF
A91516 02/09/09 03/11/09 full 03/11/09 vrF
2B0506 02/10/09 01/19/38 full 01/19/38 vKF
A91526 02/10/09 01/19/38 full 03/11/09 vKF
2B0217 02/10/09 03/12/09 full 03/10/09 vrF
A91077 02/10/09 03/12/09 full 03/12/09 vrF
2B1163 02/12/09 02/12/09 full 03/12/09 vrF
2B0685 02/23/09 03/24/09 full 03/23/09 vrF
A94073 02/23/09 03/24/09 full 03/24/09 vrF
T00602 02/24/09 05/01/09 full 05/01/09 vF
etc (from here the same all the way down)

I looked at a specific piece of media and ran nsrim -V volume to see if it marked the tape as recyclable - some of the messages which may be important are:

-----------------------
s-net1luxdc88:G:\, 6 browsable cycle(s)10066:nsrim: Failed updating continuation save set ssid `3707290228' as purged
39077:nsrim: error, Save set ssid `3707290228' the retention time is invalid

10067:nsrim: Failed updating continuation save set ssid `3707290228' as eligible
39077:nsrim: error, Save set ssid `3707290228' the retention time is invalid

9335:nsrck: WARNING: no valid save times for client 's-net1luxdc88' - cross check not performed

A93674: 308 GB used, 7 save sets, full, 1 recoverable save sets, 6 recyclable save sets
-----------------------
Note the saveset 3707290228 is not on this tape though the saveset name is and has been marked as recyclable; also all savesets for s-net1luxdc88 on this media are recyclable. These messages may therefore be red herrings?


Next I ran nsrck -L6 s-cpp-cmfe01.net1.cec.eu.int which went through as expected:

nsrck: checking index for 's-cpp-cmfe01.net1.cec.eu.int'
nsrck: /nsrsrv30/nsr/index/s-cpp-cmfe01.net1.cec.eu.int contains 3485803 records occupying 457 MB
nsrck: Completed checking 1 client(s)

And another nsrim with no effect:

A93674: 308 GB used, 7 save sets, full, 1 recoverable save sets, 6 recyclable save sets

The saveset in question here was taken 7 February with month browse and retention and with successful full backups taken afterwards so what could be preventing this saveset expiring?

ble1

14.3K Posts

June 24th, 2009 02:00

Try to add -av so that lines goes

mminfo -av -q volume=A92944|wc -l

DavidHampson

1.1K Posts

June 24th, 2009 06:00

I already did but no luck - it turns out one of the savesets still has a browse/retention of 2045 still - I am trying to recall the workaround for this but here is some strange behaviour:

ssid clone id retent clretent
1570960368 1235416048 06/24/09 07/31/45

nsrmm -e "24 June 2009" -S 1570960368/1235416048

1570960368 1235416048 01/19/38 07/31/45

nsrmm -e "1 day" -S 1570960368/1235416048

1570960368 1235416048 01/19/38 06/25/09

nsrmm -e "today" -S 1570960368/1235416048

1570960368 1235416048 06/24/09 07/31/45

nsrmm -e "24 June 2009" -S 1570960368/1235416048

1570960368 1235416048 06/24/09 07/31/45

nsrmm -e "1 day" -S 1570960368


retention policy expiration `Thu Jun 25 15:53:19 2009' must be later than browse policy expiration `Tue Jan 19 04:12:28 2038'

ssid clone id retent clretent browse

1570960368 1235416048 06/24/09 07/31/45 01/19/38

nsrmm -w "1 day" -S 1570960368

retention policy expiration `Wed Jun 24 00:00:00 2009' must be later than browse policy expiration `Thu Jun 25 15:57:41 2009'

DavidHampson

1.1K Posts

June 24th, 2009 07:00

nsrmm -e "2 day" -S 1570960368/1235416048
nsrmm -w "1 day" -S 1570960368/1235416048


1570960368 1235416048 01/19/38 06/26/09 06/25/09

nsrmm -w "1 day" -e "2 day" -S 1570960368

1570960368 1235416048 06/26/09 06/26/09 06/25/09

nsrmm -w "yesterday" -e "today" -S 1570960368

1570960368 1235416048 06/24/09 06/26/09 06/23/09

ble1

14.3K Posts

June 24th, 2009 08:00

Well, you really did a mess, didn't you :D Did you used any customer expiration time for these during backups? Clock was ok? Oh sorry, not backups, but cloning... these savesets are cloned, right? I do understand 2038 limit, but I have no idea how you managed to get 2045 for clretent :D

I know how I can get 2038 mess with PowerSnap, but not sure what is the situation there. Is there anything common to savesets which exhibit this issue?

It's interesting issue and trick would be to figure out what has caused it in first place and conditions surrounding it. Did you talk to the support?

DavidHampson

1.1K Posts

June 25th, 2009 01:00

We saw this issue at my last company after upgrading for 7.3.3 to 7.4.3 and this problem seems to date back to an upgrade here; it is possible to get the dates back to "normal dates" by doing this:

nsrmm -w "day" -e "different (later) day" -S ssid

If the dates are the same it will do strange stuff still!

DavidHampson

1.1K Posts

June 29th, 2009 02:00

The visible savesets on this tape are all confirmed as expired now after the nsrmm fix. However this tape still does not recycle after nsrim and still reports:

A92944: 45 GB used, 67 save sets, read-only, 9 browsable save sets, 58 recyclable save sets

We still have the issue of the "9 browsable save sets" which are not returned by mminfo.

DavidHampson

1.1K Posts

July 22nd, 2009 07:00

I'm not really expecting to see a resolution on this one as its stuck with one of EMC's muppets who regards cutting and pasting my case notes back to me in a different order 3 weeks later is a valid response! What I will add though is that these "ghost savesets" do get cleared down by nsrim over a period of time. We also don't seem to have any of these tapes around anymore though what was responsible is a mystery as we have had no major changes recently. I still have a concern that this data may be valid backup data that may not be visible by the recover command but whether we actually get a response on this one I don't know. If anyone has a similar problem and has a little more joy with EMC's support I would be grateful to hear more of it.

Anonymous

5 Practitioner

 • 

274.2K Posts

July 29th, 2009 15:00

I would suggest you try this.

nsrim -D 9 -vvvv -V and review the output.

Putting into debug with verbosity will give you additional information such as dependencies.

pbina

75 Posts

July 29th, 2009 17:00

Hi David,

Please run the following mminfo command.
mminfo -q "client=s-cpp-cmfe01.net1.cec.eu.int" -ot -r volume,savetime,ssretent,level,clretent,ssflags,name

These save sets seem to be VSS:\ as indicated by K in ssflags output.
Are you using snapshot backups? If yes is it hardware or software snapshots?

This is a known issue with NMMedi and NMM. The retention date being 2038 is normal and by design (explained in LGTsc31359). However, these save sets should be expired and recycled after either the snapset or the rolled over version expire whichever comes last. But, in some cases this is not happening and an escalation has been opened and still in progress to address this - LGTsc31479.

Regards...

DavidHampson

1.1K Posts

July 30th, 2009 00:00

That's a good idea Paul. If I have any media/savesets still in this state I'll take a look at the output

DavidHampson

1.1K Posts

July 30th, 2009 03:00

Hi Parviz, do you have a description of LGTsc31359/LGTsc31479 as a search on Powerlink returns nothing...

Whilst some of these tapes have had NMM with snapshots savesets on them there is nothing conclusive in them being NMM savesets as nothing is returned from mminfo. However I have seen the 2038 problem in my last company (actually it may not be the same problem as it was a 2044 problem) that did not use NMM.

pbina

75 Posts

July 30th, 2009 06:00

Hi David,
These are internal engineering escalations and you will not find them on PowerLink. Please review the following article for further explanation.

http://solutions.emc.com/emcsolutionview.asp?id=esg106764

I am not sure what you mean by ¿nothing is returned from mminfo¿. The mminfo command should output same information you extracted before plus the name of the save set that will confirm whether or not these are VSS:\ save sets.

Regards,

DavidHampson

1.1K Posts

July 30th, 2009 07:00

I couldn't access that link either.

DavidHampson

1.1K Posts

July 30th, 2009 07:00

Sorry Parviz, I'm getting mixed up with a second issue I have seen where volumes do not expire because they have savesets unlisted by the mminfo command but recognised by the nsrim command. However those savesets seem to have eventually expired and no new occurences have yet been found.

pbina

75 Posts

July 31st, 2009 05:00

That link is for esg106764 and is solely for snapshot backups. If your save sets are not snapshot backups this does not apply and they might be due a different issue. What this article says is:

After a VSS snapshot backup with NMM a save set "VSS:\" is created and registered in the media db. The retention time on this save set is "1/18/2038".
The VSS:/ save set is used to create the index records for the writers and volume nodes (GUI presentation objects).

The retention time for the 'VSS:\' save set is, by design, set to 1/18/2038. This save set will be deleted when the associated data save set has expired and is removed from the media database. This lifecycle is handled through nsrsnapck, which is automatically run at the start of a snapshot enabled group or is run automatically once every 24 hours, whichever comes first.

Regards,

View More

View All

No Events found!

Top