Missing archived after closed partition move

[CracUnBourrePif]

Hello,

 A user is complaining that he is missing 8 months of archives.
Looking in his Archive explorer, we can clearly see that his archives stop some time in November 2012, then are present again from July 2013, but nothing in between.
This user's policy removes shortcuts after 1 month so we have no way of searching for a particular item

Early in July, we moved 2 Closed partitions to a new storage. We are wondering if this could be the cause.

How coud we troubleshoot this ? I do not know "what" exactly to look for.

I guess I 'd need a way to see in which partitions an archive has item stored... I am a bit stuck tobe honnest.

Many thanks in advance for your help.

[Ben_Shorehill]

Hi there,

Sorry to hear you've got this issue. It could definitely be an issue with the movement of data. First thing you should probably do is have a look at the issue using the EVSVR tool (run verify). You need to verify the extent of the issue.

Do you have access to the original data still?

[Ben_Watts]

Why dont you try a Repair/Sync or a Full rebuild of the Index to ensure that you have all the data from storage entered into the Index.
Archive Explorer and Search Archive use the Indexes and just because it doesnt show in either AE or SA doesnt necessarily mean the item isnt in the Vault Store Partitions still.

Try a Repair on the Index First (EV9 and below) or a Synchronize (EV10) and if that doesnt change anything just do a Rebuild (All versions).

If that comes back with the same results then you have lost data basically and then you can move onto the EVSVR step as Ben mentions above.

There are SQL queries you can run to find out if there are references in the tables to items between those dates too, for example:-
(Run it against the relevant Vault Store DB)

 
 ----------- START OF QUERY -----------------
 
  DECLARE @Date1 datetime
  DECLARE @Date2 datetime
  DECLARE @ArchiveName Nvarchar(36)
 
 
  SET @Date1 = '2012-11-01'
  SET @Date2 = '2013-07-01'
  SET @ArchiveName = NULL --Add an Archive Name to filter a particular archive
  
  
  --Drop temp table if already exists
  IF object_id('tempdb..#temp') is not NULL
  BEGIN
     Drop table  #temp
 END
 
 SELECT
     Archive.ArchiveName,
     ArchivePoint.ArchivePointId,
     @Date1 AS DateFrom, @Date2 as DateTo,
     COUNT(*)Items,
     SUM(ItemSize) AS DVSSize_kb,
     SUM(OriginalSize)/1024 AS OrignalSize_KB
 FROM
     EnterpriseVaultDirectory.dbo.Archive Archive
     JOIN EnterpriseVaultDirectory.dbo.Root RT on Archive.rootidentity = RT.rootidentity
     JOIN ArchivePoint on RT.VaultEntryId = ArchivePoint.ArchivePointId
     JOIN Saveset on ArchivePoint.ArchivePointIdentity = Saveset.ArchivePointIdentity
     JOIN SavesetProperty SP on Saveset.SavesetIdentity = SP.SavesetIdentity
 WHERE   
     Saveset.ArchivedDate > @Date1
     AND Saveset.ArchivedDate < @Date2 
     AND Archive.ArchiveName =  ISNULL(@ArchiveName, Archive.ArchiveName)
        
 GROUP BY
     ArchiveName,
     ArchivePoint.ArchivePointId

 ----------- END OF QUERY -----------------

[CracUnBourrePif]

Just to clarify : the partitions that we moved were closed in 2008 and 2011 respectively. Could they possibly contain items from 2012 and 2013 ? Or is my understanding of Closed Partitions wrong?

There used to be an article named "About Enterprise Vault Closed Partitions", but it seems like it is not online anylonger.

Thx again,

Vincent

[GabeV]

Hi,

In the PartitionEntry table (Enterprise Vault Directory database) you can determine exactly when these two partitions where open and closed. If you know the date range where this data is missing from this particular archive, you can tell if the archived data was in any of these two partitions or not. If not, I do not think that the fact you moved 2 partitions to a new storage would be the cause for this issue. If that's the case, then something else happened.

Check the index volumes and verify if they are in failed state. If not, you can run EVSVR against this archive and specify a date range. If EVSVR generates errors, then you need to follow the DR process to recover the data for this archive.

I hope this helps.

[Ben_Watts]

Hi CracUnourrnePif,

No those close partitions would only contain data that was archived into them BEFORE they were closed, so anything that is 'missing' wouldnt be in those Partitions.

Best to check that SQL Query out as it will easily tell you if there is MEANT to be any DVS files in his archive.

If that comes back with results then next step is to work on the Indexes as they may be missing content. OP states that the missing items were checked via Archive Explorer and Search Archive, both use the Indexes for results, if items are missing from the Index then all that needs to happen is a Repair/Sync or Rebuild of the Index and Voila items are back and avialable again!!

No point in complicating things with EVSVR at this point in time in my opinion, also if EVSVR does need to be run and then returns errors I suggest opening a Support case so that we can help you through it as those errors will need to be looked into and see if they are fixable or not before you go down the painful route of a complete DR situation.

[CracUnBourrePif]

Hello,

I ran the SQL query, and altough it returns few lines, it DOES return lines, only maybe a few items per day or week, which does not match the usua usage of this highly used mailbox.

I then checked the index, but they show no failure, so I can't reparir them. I ran an IndexCheck -c MissingDocs, but it remained the same.

I then ran an EVSRV on the mailbox, with this (partial) result :

Verify that Collection reference counts are correct
---------------------------------------------------

Collection records: 5478

Collection file path: \\STG\vaultstore\STG_Ptn10\2012\04-19\0\Collection557669.CAB, Identity: 557669, TotalCount: 55, RefCount: 14
Collection Reference Counts do not match. VS DB TotalCount: 55, VS DB RefCount: 14, VS DB Saveset record count: 0, FP DB SISPart and Converted Content record count: 0

Collection file path: \\STG\vaultstore\STG_Ptn10\2012\04-19\0\Collection791545.CAB, Identity: 791545, TotalCount: 55, RefCount: 55
Collection Reference Counts do not match. VS DB TotalCount: 55, VS DB RefCount: 55, VS DB Saveset record count: 41, FP DB SISPart and Converted Content record count: 0

Collection file path: \\STG\vaultstore\STG_Ptn10\2012\04-24\1\Collection801412.CAB, Identity: 801412, TotalCount: 13, RefCount: 13
Collection Reference Counts do not match. VS DB TotalCount: 13, VS DB RefCount: 13, VS DB Saveset record count: 9, FP DB SISPart and Converted Content record count: 0

Collection file path: \\STG\vaultstore\STG_Ptn10\2012\04-24\1\Collection801428.CAB, Identity: 801428, TotalCount: 21, RefCount: 21
Collection Reference Counts do not match. VS DB TotalCount: 21, VS DB RefCount: 21, VS DB Saveset record count: 11, FP DB SISPart and Converted Content record count: 0

Collection file path: \\STG\vaultstore\STG_Ptn10\2012\04-24\1\Collection801429.CAB, Identity: 801429, TotalCount: 28, RefCount: 28
Collection Reference Counts do not match. VS DB TotalCount: 28, VS DB RefCount: 28, VS DB Saveset record count: 3, FP DB SISPart and Converted Content record count: 0

Collections processed:                 5478
Collections with mismatched RefCounts: 5
Collections with invalid records:      0

So there seems to be mismatches, but just a few, considered that we are missing A LOT of content.

[JesusWept3 · Accepted solution]

Even if you were missing emails from a partition, unless you rebuilt the index, it wouldn't affect archive explorer as that represents what the index has, not what the archive currently has If the SQL query Ben gave you shows some results but not as much as you'd expect then that would indicate more that his archive just hasn't been processed that much, maybe the tasks were giving 3310's? Maybe it just never had time to get to his mailbox Also do you allow users to delete etc? I really don't think you have missing data from storage or index based on what you've said