Save sets have status browsable too long time

Not only MSSQL-Save Sets are affected as you can see from the second screenshot attached at the bottom.

There are also a few Save Sets with Full Level Backup affected.

I will try to get the information you asked for and will come back to you...

Hi,

The savesets that are still browsable are all incremental backups so their recycling is probably being affected by the full versions of these backups.  This can be a bit confusing but it is explained well in the below article:

Explain the affects of continuation, and dependent save sets in regards to volumes being marked recyclable

-Bobby

And another Screenshot with Full and browsable Save Sets

It looks as if it applies to MSSQL savesets only, right?  incr level is transaction log backup, but I assume NW might be using it's own logic of building incrementals upon fulls here for cycle expiration and we do not see when or where full backups are.  Picture also doesn't reveal what ssretent is which could be seen with mminfo.  If you do mminfo -avot -q 'client= ,name=MSSQL:' -r 'name,level,savetime(20),ssretent(20)' you will get a timeline which one could examine then for start.  Based on server version, I assume you use Siemens version of it.  What is the version of SQL module? (build matters)

Thanks for the helpful posts.

Now every entry is explainable for me, but one is not:

Browse and retention policy is set to 2 weeks. Why can I still browse the backups from 6th of march to 11th of march as these should be obsolete from 25th of March? Just wondering if there is a bug in the version? Or does it just take some time?

Full be browsable for 2 weeks plus incremental cycle... this means 2 weeks + 1 week of incrementa which is 3 weeks.  So ideally, on 30th or 31st it should be expired.

The one done on 6th will last until 6+21 which is 27th midnight... so actually today... and its expiration depends on when your scheduled nsrim process will start to run within the day today.  If on UNIX platform, you can check timestamp on file called nsrim.prv in /nsr/mm directory (not sure if the same applies to Windows, but I guess it might).  This process runs once per day and does crosscheck which in return does cleanup as well.  You can manually initiate it with nsrim -X command or to isolate it to particula client run nsrim -c -X and afterwards you should be fine.

Actually, since last incremental on that cycle is done on 11th that would be 11+14 which is 25th so on 26th that cycle should be expired.  It is a bit odd to see it still there as browsable if 2 weeks is retention period.  Try from command line to see what ssretent is set on those save sets using mminfo command.

I've found a SaveSet with even more days (see new attachment at the bottom, screenshot from today, 29th of March 2011, taken 10.45 am [Central European Time / Greenwich Meantime + 1]).

Would the command be

mminfo -avot -q 'client=cl10srv_vol14,name=vol14:' -r 'name,level,savetime(20),ssretent(20)'

to get the information needed? So what would you suggest? That there is a Save Set retention time that I cannot configure with the GUI but only with the CLI? I'll post the result of the command today...

Hi,

You should add a couple of other columns to your query to get a clearer picture:

mminfo -avot -q 'client=cl10srv_vol14,name=vol14:' -r "savetime(20),level,sumflags,ssbrowse,clretent(20),volume,volretent"

It is better to use the 'clretent' value instead of the 'ssretent' as this will give you the retention of each clone-instance of the saveset.  If you use cloning, then the 'ssretent' will correspond to the latest retention of all clone instances and not the actual retention on the saveset-instance that is on this volume.

-Bobby

That's a good point, but note that pictures show status of index and browse policy can't be different for clones indicating ssbrowse for cycle hasn't been either reached or nsrim check didn't run for some reason.  So checking ssbrowse field should be included too in mminfo query.

Hi Bobby,

attached a screenshot from today, 12th of April 2:05 pm CET:

I have results from today for one of the clients produced with the following command:

mminfo -avot -q 'client=cl10srv_home9,name=home9:' -r 'savetime(20),level,sumflags,ssbrowse,clretent(20),volume,volretent'

Many thanks to everyone.

Everything is clear to me now!

Jens Fuchs wrote: Many thanks to everyone. Everything is clear to me now!

And in case that it's not to someone, the icrementals in that backup cycle are keeping away full to expire as those incrementals depend on full.  Thus, this will expire on 15th on April.  It is fair to say that member of backp cycle will expire after farest retetion of backup cycle's memeber has been reached.