Where is: http://entsupport.symantec.com/umi/ v-269-8

[Bernhard_Schnab]

Hello,

I could not find the article: http://entsupport.symantec.com/umi/ v-269-8

Many articles link to this, but it seems that all articles links only to other links an there is a circle.

Could anyone find the article and post it here?

Thanks!

Kind Regards

Bernhard

[AmolB]

Post the error message from the job log

[Bernhard_Schnab]

Hello,

There is no error message, I want to find this knowledge base article.

http://entsupport.symantec.com/umi/v-269-8

I want to know, if anyone can read this article.

Kind Regards

Bernhard

[Colin_Weaver]

As that obviously does not work please advise on where you found that URL (which is why other's asked you for the error message) as we then might be able to help you find the missing article (or in my case chase up internally on why it is missing.)

EDIT: OK I just found what you are referring to - it relates to a registry entry to make more than one overwriteable IMG folder be removed whevener we try to reclaim IMG space.

The default is 1 and as far as I know the registry key change in question was only ever intended to be used under the guidance of Tech Support because we need to be able to monitor why customers think they need to use it.

In normal operation of IMG folders every time a backup set that creates a unique IMG starts it will look for at least one IMG folder to reclaim (in other words delete) as such if everything is working as expected and as long as overwrite potection is not applying) you should only be deleting exactly the same number of IMG as you are creating. If you apply the modification then it will attempt to delete more than 1 IMG which in theory deletes more IMG folders than you are creating, which should never really be needed.

[Bernhard_Schnab]

Hello Colin,

I found the link at different location for example: admin guide Page 513 or here:

http://www.symantec.com/business/support/index?page=content&id=HOWTO22727&actp=search&viewlocale=en_...

Kind Regards

Bernhard

[Colin_Weaver]

OK I was editing my original post as I found what the reference meant before I saw your original reply - as such see my previous edited answer.

The only things that really concerns me is why this reference exists in any public documents at all

[Bernhard_Schnab]

Hello Colin,

Thank you for the answer.

The reason to change the value ist, that at serveral installations it ist the same fact, that over some weeks the backup to disk folders are full with old .img files. Some of these files must be deleted manually. If not the backups stops and the backup to disk folder is offline.

On my opinion this registry key should be set to 2 as default.

Is it possible to send me the registry key, without to open a call? Because that costs a lot of time...

Kind Regards

Bernhard

[Colin_Weaver]

As it happens the reg key is also currently a public document

http://www.symantec.com/docs/TECH52886

However as every installation should delete at least one file I am not sure changing it will help you as you probably have another problem affecting your environment if your servers are not reclaiming the IMG correctly. As such that other problem will probably need a support case anyway. If you look inthe Alerts section of the Backup Exec console do you see sucessful reclaim events being recorded when your GRT jobs are running?

Note: I have asked internally about the faulty link and the reason for customers needing to change the setting in the first place.

[Bernhard_Schnab]

Hello Colin,

Thank you for this information.

As it is discribed int the document TECH52886 the default is 3. I set it to 3 now and will look after some weeks, if it solved the problems.

For your information:

There are normally no problems with the backups. In the Alert Section the successfully relclaim Messages are recorded. But over a long time there are too much .img files.  It seems to be a normal behavior, because nothing is perfect.

Kind Regards

Bernhard

[Colin_Weaver]

The default of 3 mentioned in that document is wrong - the default is and always has been 1 - as such I am going to get the document edited in the next 24 hours to reflect the correct default

[Bernhard_Schnab]

Hello Colin,

Please do not change the oikument, but the default in the next version, i think it will be better for all customers.

And thank you for your help, I searched for this key a long time.

Kind Regards

Berhard

[Colin_Weaver]

as previously described if the product is working as designed thene there should be no reason to change the default from 1 - however if you have a valid technical reason why you think it should be more than 1, you can fill in an enhancement request using the Ideas section of our community forums. To get to this use the "Create Content" tab near the top of the forum pages and click on ideas