EVSVR Output

[EVUserAB]

I just repaired a 9.0.2 Vault Store partition and saw this result for several savesets.

"2011-08-16 09:20:37            SavesetId: 974000000000000~200812051817360000~1~635EAC9930AA4177B0B3DCB9140289A, Archived Date: 2008-12-19 23:00:00Z
2011-08-16 09:20:37             ArchiveEntryId: 124238AE079D9F44996AE2A1AE5648C8F1110000UKVault1
2011-08-16 09:20:37              Current File Path: \\UKBSHIGEXG004\EVPartition01cb6cd77b7b07a0$\2008\12\05\18\974000000000000~200812051817360000~1.DVS
2011-08-16 09:20:37               Error: The system cannot find the file specified.  (0x80070002)
2011-08-16 09:20:37                EVSVR action: Removal of Surplus Saveset failed. Error: Error reading Vault Entry from Vault Directory  %1      (0xc00418e7)"

Does this mean that it could not remove a database entry or a file from the vault partition?

Any information would be helpful as to what this means.

[JesusWept3 · Accepted solution]

So by the looks of it, it's found a "duplicate" saveset in the database
(if you notice you have the ~1 at the end)

What its attempting to do first of all is just physically delete the file, then remove the database entry
First error is the file doesn't exist (maybe its collected? or maybe it genuinely is gone) but if it doesn't exist, doesn't matter because we were about to delete it anyway.

The next part is the real  error where it can't read the vault Entry ID
So typically you would run the following query

USE yourVaultStore
SELECT * FROM Saveset WHERE idTransaction = '635EAC99-30AA-4177-B0B3-DCB9140289A0'

Note the VaultIdentity number returned (will be like 1234)
Next run the following query

USE yourVaultStore
SELECT * FROM Vault WHERE vaultIdentity = 1234

Does this return any results?
The Vault itself actually refers to a folder, so in the Saveset table you will have "ArchivePointIdentity" and "VaultIdentity", an ArchivePoint is an actual Archive, and a Vault is a folder.

If it does return a result from the Vault query, note down the VaultID (its a long GUID) and then run the following query

USE EnterpriseVaultDirectory
SELECT * FROM Root WHERE VaultEntryId = '1000077546AB82DFB243E22C23B0159A1110000EVSite'

If this returns something, note the RootIdentity (like 1234) and then run the following query

USE EnterpriseVaultDirectory
SELECT * FROM ArchiveFolder WHERE RootIdentity = 1234

Somewhere along the line though i expect one of these queries to return no results.
You can also determine who the user is that it is mentioning by copying the Archive ID then going to the Vault Admin console, holding CTRL-SHIFT and right clicking "Archives" and then selected "Find Archive or Folder" and then pasting the Archive ID in

[EVUserAB]

Ok.  Thank you for the queries.  The first two queries returned data, the FROM ROOT WHERE query did not.

So does this mean that this archive no longer exists?  If not, do I need to worry about these entries in the log prior to using MoveArchive to close out the site?

Thank you

[JesusWept3]

Move archive may actually fail to be honest What it sounds like is at some point you may have done a disaster recovery ofthe directory database Basically when you archive an item in a folder, if that folder hasn't been archived before, it will create an entry in the archive folder and the root table in the directory database and an entry in the vault database Let's say you backup your databases at midnight, then someone archives an item in a new folder, then you have a failed/suspect directory database, you restore it from the midnight backup but you dot restore the vault store db's, you now have an entry in the vault table of the vault store databas but no entry in the directory database in the root or archivefolder tables In all honesty you may need to contact support on how to rectify this I would also do a query to see how many other items it might be impacting SELECT COUNT(idTransaction) "orphaned items" FROM Saveset WHERE VaultIdentity = yourvaultid This will tell you how many items were archived in that orphaned folder and wouldn't be retrievable either (I'm assuming you'd see something in evsvr about this)