Video Screencast Help

Need Help Reconciling

Created: 30 Jan 2008 • Updated: 25 Nov 2012 | 6 comments
This issue has been solved. See solution.

Back when our vault was a KVS branded vault there was a data issue (around 2004). After they got the vault working there was some data loss, but we moved on. Whats happening now is that when I try to rebuild indexes the indexer is trying to find data files that don't exist anymore, but must still be referenced in the SQL database.  If the indexer hits too many errors in a row, it stops indexing the archive and fails it out. It only impacts users who experienced loss in that time frame.

So I'm looking for potential quickfixes and resolves.

Is there a regkey to tell the indexer to ignore more errors and finish indexing even if it hits a few hundred errors? (again these are references to email we've already made peace with losing)

Is there a way to have the vault reconcile the data to the database so that the bogus entries are removed?

Any help is appreciated.

EventID 7287

Unable to add the item to the index since it is not currently available from the Storage Service.

Reason: Error processing saveset [0xc0041923]

Attempt: 2

Index: 1BC2A46E257639245838E21F95F4071491110000kvsvault/Volume:109 (USER NAME)

Saveset Id: 204000000000000~200403231933410000~0~6218043DA5C742A89458ED06688DB61

Sequence Number: 8328

For more information, see Help and Support Center at

Discussion Filed Under:

Comments 6 CommentsJump to latest comment

TonySterling's picture
You should open a case with support and ask for help running VSVerify or EV Centera Checker depending on your back end storage.
596707540's picture
Our Support agreement is in process of nenewal.... (insert irony here) It happens to have just expired and we're in the quote/po processs to renew.
Will open as soon as possible, just looking for a way to get the indexes that won't finish up for the moment, and then clean up the SQL data with support in the next couple days.
Any other thoughts?
BTW Vault 7.0 SP3
TonySterling's picture
I think if you reach out to your Account rep and request a 1 time exception for support whilst the paper work is being processed you should be able to get some help.  That would be the best way.  :)
Michael Bilsborough's picture
There should be an event saying that because 25 consequtive items have failed to be added so the indexed update is being halted.  is that the kind of event you are seeing?
596707540's picture
Update. Found out that our support agreement was actually renewed last month so I'll be talking to them soon.
However, I'd already come up with a fix.
I queried the ArchivePoint table to get the archivepointId using the users' vault IDs.(select archivepointid,archivepointidentity from ArchivePoint where archivepointID = '18E2C014F911A3E48925E20BF95F6BF411110000kvsvault' )
I then combined that with the Vault Parition ID that was having the problems
to get a listing of all the vault records for that user.
(select * from saveset where archivepointidentity = 43 and Idpartition = 0)
I then wrote a spreadsheet to concatenate all the info from the record to create the actual filename and path.
I cut and paste the records into my sheet to create a list of all the paths and filenames for records that the database thinks is actaully in the filesystem. Then I used a python script on the actual vault server to check for the existance of each file. ( I manually checked a few to make sure I didn't screw up anything). The python script dumped out a yes/no answer to each path/filename. I put that back into my sheet, filtered it by the "nos" and used another concatenation field to create the SQL delete queries for the records that pointed to files that didn't actually exist. Since collections was never enabled on this partition this method worked. It would have been more complex if collections were enabled.
After I delete the records from the database (since the files aren't there anyway) I used the indexVolumeReplay to rebuild the indexes.
LIfe is good again and everything is fine.
I still wish there was a tool that did all that for me.
/I had backups of everything.
/I don't work for Symantec(or Veritas, or KVS) so this may not be a supported fix. It just worked for me.
MarkBarefoot's picture
The VSVerify tool actually does that. You can run it against a single vault or all vaults and it will produce a list of what is in the database, any issues with the data, missing DVS files etc. You can then re-run it to delete orphaned entries (as in no corresponding DVS files). Sounds like you made your own version though :)
VSVerify and DVSChecker are tools that are issued by Support - both are fairly intensive on overheads but if you are in a position where you have missing savesets or SQL entries then you really need to use them - or just take it on the chin that some of your data will not be accessible.
I'm surprised you had this issue if you had all the corresponding backups available though.....
Good work though!



Supportability Analysis Engineer for Enterprise Vault products.