Certain Archived Items have an Incorrect ArchivedDate and IDCheckSumHigh within the Saveset Table
|Article:TECH209243|||||Created: 2013-08-01|||||Updated: 2014-12-15|||||Article URL http://www.symantec.com/docs/TECH209243|
Certain Archived Items have an incorrect ArchivedDate stored in Saveset Table (within the VaultStore SQL Database).
For example, an Item is archived on the 24th of April 2012.
- The location on Disk is:
- Within the Saveset table, the ArchivedDate field should be recorded as the 24th of April:
However, the date is being recorded as the 23rd:
- If Collection is enabled, the file will then be collected under the following location:
This problem will give the impression that the Saveset on Disk has actually been manually moved to a different location.
A repair with EVSVR currently does not work as EVSVR is picking the date as the 23rd of April.
Error ID 6838 can be logged in the Enterprise Vault (EV) Event log
(In this instance, Collection is Enabled)
Time: 4:54:13 PM
Source: Enterprise Vault
Category: Storage Online
Failed to recall a Saveset from its Collection.
Reason: The system cannot find the file specified. (0x80070002)
Relative Saveset Filename: 2011\09-18\5\E34\5E347D5058FF4A96AA5453C92C72B870.DVS
Relative Collection Filename: 2011\09-18\5\Collection30171.cab
Partition Root Path: E:\Enterprise Vault Stores\2011EV
Migrated File Id:
For more information, see Help and Support Center at http://entced.symantec.com/entt?product=ev&language=english&version=10.0.3.0&build=10.0.3.1090&error=V-437-6838
The issue has been reported on the following versions of Enterprise Vault
Only partitions using NTFS File System have been seen to experience this issue
Saveset records in VSDB have incorrect Archivedate and IDCheckSumHigh
Article URL http://www.symantec.com/docs/TECH209243