EV 6.0 for Ex : xxx savesets that are waiting to be indexed/backed up

[Matthew_Millers]

Hi,

I receive the following event when the monitoring task runs...

Event Type:Warning
Event Source:Enterprise Vault
Event Category:Monitoring
Event ID: 41021
Date:18/01/2007
Time:11:59:59
User:N/A
Description:
There are 686104 savesets that are waiting to be indexed and/or waiting to be backed up or replicated in Vault Store

What is this referring to exactly?!

At the moment we do the following back ups...

Weekly Full
1. Run file to stop/start services and set EV into RO mode
2. Backup the EV SQL dbs using agent (full)
3. Backup the master/msdb databases using agent (full)
4. Backup the following directories : Indexes ; Shopping ; Enterprise Vault (full)
5. Run file to stop/start services and set EV into RW mode

Daily Differential
1. Run file to stop/start services and set EV into RO mode
2. Backup the EV SQL dbs using agent (full)
3. Backup the master/msdb databases using agent (full)
4. Backup the following directories : Indexes ; Shopping ; Enterprise Vault (diff)
5. Run file to stop/start services and set EV into RW mode

Are the saveset alerts being generated based on the archive bit of the filesystem? Is there something else that i need to backup to make the waiting savesets go down?

Any help is appreciated.

Thanks
Matthew

[Alan_M]

The error you are getting is being caused by the archive bit not being cleared. So if you are archiving every night the differential backup will not be clearing the archive bit leading to the warning.

[Michael_Bilsbor]

There is a 'trigger file' mechanism you can use for this.

You will know if this is the root cause because you would expect to not see these
errors after your full backups.

[Matthew_Mille1]

How do i get the trigger file mechanism to work?

[Michael_Bilsbor]

check the documentation it covers it pretty well.

[Matthew_Millers]

Hi,

I have done everything that the doco says to do. After the diff backup i write a file (IgnoreArchiveBitTrigger.txt) to the root of the index volume, then the services are restarted and the archive set back to RW mode.

I dont see that anything is happening to the trigger file. The doco says that it will check that the file exists when the storage service is restarted, if it exists the file will be renamed or deleted, this does not appear to be happening.

Is there any extra logging that can be enabled to troublshoot

1. Current saveset status
2. Whats happening with the trigger file process

One other thing, i set the monitoring > watchfile frequency to be 15mins with threshold 0, it would seem that this is not working either, no events are being logged.

Your assistance is appreciated.

Thanks
Matthew

[Micah_Wyenn]

*cough* Set the vault store to remove pending files immediately after archive? :)

micah

[Michael_Bilsbor]

"root of the index volume"

is not right, it needs to be in the partition. check the docs again.

[MarkBarefoot]

Where are the savesets actually being stored? By your posts I would presume on the EV server (?). Are they being stored onto a NTFS partition? NetApp? Centera??

You could do a quick check to see if its on NTFS and run the attrib command in one of the folders.

Are your archiving/backup schedules working ok without conflicting? I have seen this cause a problem when the backup runs during an archiving window - not a good idea!

You could also look at the FileWatchScanInterval reg key (which by default is 12 hours and immediately after the Storage service restarts).

[Matthew_Millers]

Hi,

I am pretty sure that this is not working properly, i have changed to a incremental job for the index volume which should reset the archive attribute.

Now i have a different problem, i manually deleted the "IgnoreArchiveBitTrigger.txt" file from the partition, some time later i notice that the exchange server is performing quite badly, looking at the rpc requests, this appears to be twice the amount that is generally seen. Running exmon shows the top 10 connections are coming from the EV server.

Could someone explain what is happening here? Is it resyncing? Is there any way to stop this from happening?

I placed the file back into the root of the partition, restarted the EV services, noticed that the RPC usage went down somewhat, that said, it is now back up to where it was originally.

Any help would be appreciated.

Matthew