Can anyone help me.
We have several Enterprise Vault archiving servers. Most of the wok fine, but there is one with a large ammount of saveset (close to 7.000.000).
Off course the event viewer now display a lot of 41021 and 41008 event-id's.
I have checked for the ignorearchivetrigger.txt, but this one is present and in the right location.
I dont see the .old file though. So it appears the backup doesn't change the extention of the file.
What can i do?
Solved! Go to Solution.
How old is the file ignorearchivebittrigger.txt ?
Is the file being created by your backup tool ? See this technote for a pre/post script:
Since Enterprise Vault uses the created date of the file I would look at what the date of that file is as a starting point.
Also there were some issues on 8.0.3 are there any errors reported from the StorageFileWatch process?
I can testify that the process of backup and having the backup write the IgnoreArchiveBitTrigger.txt is ok, as I configured it at that customer.
I've told rob to check if it is not a new location, or perhaps a missed one. I also advised to check eventviewer. I hope he replies here to let us know if the issue is resolved.
Way ahead of you ;)
Like i said i'm already in report mode. looks like the amount of savesets is dropping :).
But now i'm running into the event id 7109. And this causes the next issue.
And already got the 6265 id.
So i made i proactive reboot of the system before it goes in back-up mode
If you see the event 6265, it is indicating a lack of memory issue. Although it says 'not enough storage available for operation', this issue is related to RAM. On that server, check task-manager, performance. Check to see what the memory usage is.
If it is high, perhaps you can have the VM-team give you an extra 2 GB of Ram (machine now has 1.5 right?) for the time that is needed to work away the savesets.
If I recall correctly, last time this happened, we had the task in report mode for about a week before the savesets were processed.
This is (btw) another reason to upgrade to 9.03. In 9.03 some improvements have been done in regards to memoryusage/leaks/performance etc. Might be an extra handle to convince people to upgrade....
I did, and seemed fine. But event 6265 is often followed by event 4183. So to prevent ev from shutting down during back up mode i restarted it pryor to the back up. since than i haven't seen event 7109 as well.
There was a new VM Best Practice guide published in January this year. It is mainly around EV10 but you may find it useful to at least read through to see if there are any nuggets of info.
The number of savesets appears to be going down, but very slowly. It's now at about 6.700000. But it's weird. It goes down, at one point we were at 6.400000. Although in report mode constantly sometimes the amount of savesets still adds. How is this possible in report mode?
Are you sure the store remains in backup-mode? Is it not taken out of backup by the backup-software by accident?
If I recall correctly, there should be a batchfile that is called by the backup software to set/clear backup mode. Try to locate these, and either rename, or rem out the command that clears backup mode.
On the affected server, check the eventlog for event 7080 (clearing backup mode). If you see this happening, the command is run from somewhere.
I found a bunch of batch files for pre and post back up. however i can not find the command that clears backup mode. But i'm going to check with the batch files on other ev servers to see if there are different command or settings