/nsr/index grows and grows and grows

Browse & Retention Policies are relative periods - when they are applied to a backup, they will be converted to absolute days/timestamps.

There are a few ways to reduce the indexes. They are all save set based operations using 'nsrmm'.

To get the ssid & cloneid (important when you have clones), use 'mminfo':

  mminfo -q "your_query_pameters" -r "ssid, cloneid" -xc/ > outfile

If you use mminfo to report more than 1 attribute, you must delete the headline of the output file before you proceed.

You then either redefine the browse date for the save set or set the save set to 'recoverable'.

For both methods it makes sense to use the command line to generate SSID which you then can process via scripts to the 'nsrmm' command (as a precaution, you cannot use SSID list files as input file).

   nsrmm –o recoverable  –y –S ssid[/cloneid]

   nsrmm –S ssid[/cloneid] –w browse-time –y

Then run 'nsrim' or wait until NW will do it by itself. 

??? - index management should be started by the NW server itself (once a day, if I remember correctly).

Please verify the status of your save sets and their browse and retention dates.

Hi bingo,

three month back where I changed the browse policy from "2 Years" to "Quarter", I also changed every saveset with nsrmm. But I did not run the nsrim after that. I will do this now and see if the size of /nsr/index will get smaller.

Thanks!

Yes, you are right.

But still I don't why the index grows so much. The oldest save set which I can browse is 3 month (quarter) and my index is still getting bigger. I'm not backing up more data, even fewer (number of files) compared to three month ago. So the index should get smaller by itself. But it doesn't.

Please run the following command:

   mminfo -q "client=your_client,savetime>-3months" -r "client,name,level,savetime(25),sumsize,sumflags,ssbrowse,ssretent,volume" -ot

and let us know the output.

So we now know that the brows/retention dates are in fact longer than expected.

Sometime they are equal but none of them passed the browse data yet.

Consequently their CFI has not been released yet.

So far only you might know why this is the case because only you know your configuration.

May I suggest you take one specific (older) save set and try to manipulate him with nsrmm as I suggested.

Let's see whether the 'cleanup' works at least.

So, I did find appr. 1000 save sets which had a browse retention with something going until 2019. I changed these 1000 save sets to quarter (01/30/2018) with nsrmm.

I the double checked with mminfo and all the save sets above are until 01/30/2018 now.

I hope this gives me a little air to breath on the /nsr/index.

I also discovered that I have thousands of save sets with a browse policy which is in the past. I do not understand this at all.

These save sets belong to backups which were cloned to a tape library.

Just do not forget that this is a forum.

Anyone who will respond and try to help you has to live with the (often) fractions the user states.

Thinking/guessing what he might have ment is often the hardest part for a supporter.

Yes, we are talking personally but my personal intention is to clarify the technical facts for every potential reader.

Especially if someone searches the forum later.

Whether you my style or not - I personally do not really care.

I don't understand this as well - what do you want us to tell?

May I first suggest that you use the right terminology - it will help you to understand the technical facts better:

  - You cannot verify the 'browse/retention policies'.

      These are relative periods which you define. You only see them in the client resource definition.

   - From the media index (mminfo) you see only the 'browse/retention dates'.

      Based on the policies, the actual time stamp plus the appropriate policy will be converted into an absolute time stamp

      which will finally be stored in the media index.

Of course the browse policy can be shorter than the retention policy. This has been the NW default for more than 20 years.

And you use this yourself as you mentioned in your opening statement.

If the policies (and their associated time stamps) are different, of course the browse date could already have been passed.

Even the retention date could have been passed. Such 'expired' save set will only 'disappear' (be deteleted) if it was stored on a disk medium where they are stored in separate entities. You cannot delete a single save set from a tape.

So far, there is nothing unusual with respect to your statement.

Returning to your original problem:

If the CFI (index) information is still there - in other words: if their browse date has already passed (the SS status should be 'recoverable') but if their client file index is still present (which btw is not easy to verify) - such would be unexpected.

But you did not state that so far.

Thanks for the little lecture here. I know NetWorker for the, by you mentioned, 20 years now and I don't think you are new to it. So you know what I mean when I say policy or whatever, so don't pretend to be my highschool teacher here. But thanks so far for your help. Really appreciate it!

Can someone else help me with the problem that my CFI is growing so fast?