Overview
An archive store can appear to be Rebuilding or Merging in the console indefinitely while, in reality, no indexing is happening for that store. This occurs when a required merge of the store's sub-indexes fails on every attempt, which blocks the store from synchronising. New mdail for the current month may still index, so the store continues to look healthy, but older months are never searchable.
This article explains how to recognise this specific condition, what causes it, and how to recover.
Environment
- GFI Archiver
- All supported environments
Symptoms
- One or more archive stores show as Rebuilding/Merging (or simply "running") in Configuration > Archive Stores, but the on-disk index folder for that store does not grow over hours or days.
- Searches against the affected month(s) return no results, while the most recent month still returns results.
- The console shows no error or warning for the affected store — its state looks normal.
How to confirm (diagnostic)
The console state alone is not reliable here; confirm from the Search debug logs, located at <GFI Root>\Archiver\Search\DebugLogs\:
-
Merge.logshows the same store's merge failing repeatedly, for example:- Merge reason
exceeded maximum subindices, followed by a failure. dtSearch error 203 … [R792] Invalid vector itemreferencing a sub-index path such as…\index0.- The failure repeats on a regular cycle (for example, hourly), with the attempt count climbing and every attempt failing.
- Merge reason
- The indexing log then records
Index not synchronised since it must be merged firstfor the affected store, meaning the store is gated behind a merge that can never complete. Index.logshows noSync […] in bulk mode/Bulk to normallines for the affected month(s), i.e. genuine indexing is not occurring for them, even though the state reads as Rebuilding/Merging.
If you see the pattern above, the store is stuck behind a failing merge on a damaged sub-index; it is not making progress.
Cause
One of the store's sub-indexes (commonly index0) is damaged, so the merge that GFI Archiver needs to run before it can synchronise the store fails every time with a dtSearch 203 Invalid vector item error. Because the merge never succeeds, the store is permanently skipped.
Sub-index damage of this kind is typically introduced by an abrupt interruption while the index was being written — most often the volume hosting the index running out of free disk space, or an unexpected service/server stop during a merge.
Resolution
Important: These steps delete and rebuild the index for the affected store. Perform them during off-peak hours and rebuild one store at a time. Rebuilding can take from minutes to several hours depending on the store size.
- Free up disk space first. On the volume that hosts the index (the Path to search index shown under the store's Summary), confirm there is ample free space before rebuilding; as a guideline, at least 3× the size of the largest affected month's index folder. If the original failure was caused by a full disk, rebuilding without free space will simply fail again.
- Exclude Archiver folders from antivirus scanning and confirm the index location is on the Archiver server with valid access credentials (see Archiver Search Returns Zero or Incorrect Results).
- Perform a forced rebuild of the affected store's index using Method 2 – Forced Rebuild in Rebuild an Archive Store Index: stop the GFI Archiver Search service, delete the affected store's Index Folder from disk, then start the Search service so Archiver builds a fresh index.
- Track real progress in the logs, not just the console state. In
Index.log, aSync […] in bulk modeline followed by new messages confirms the store is genuinely indexing. The store will show as Invalid during a forced rebuild (the index is missing), which is expected; it returns to Online when complete.
Testing
When the rebuild completes and the store returns to Online, run a search from the Archive tab for mail in the previously affected month(s) and confirm results are now returned.
Ibiso Barimalaa
Comments