Migrating EV vault stores and confirming an email is in the new location

[Rem_y]

I have a scenario where EV vault stores are being migrated from A to B

No problem, just follow the following: http://www.symantec.com/docs/TECH35742

Then I'm asked the following - even if every last detail of the TechNote was followed, how can you be sure everything has copied from A to B without problem?

I say, 'use EVSVR'. Run it against A and B, compare the results

Still not satisfied with the answer, I'm asked if I can find a way of indentifying an email located in source (A) that will end up on target (B), so it can be proven the email is now in the new storage location

I've got as far as below, and then stalled - I have a feeling I'm making a right mountain out of a mole hill. Can someone sanity check this process and suggest any more practical ways of establishing this information?

SELECT [IdTransaction]

,[IdDateTime]

,[ArchivedDate]

FROM [EVVSEMAILVaultStore2_2].[dbo].[Saveset] (NOLOCK)

where IDTransaction ='70C05AEE-3F2E-BF65-BCF3-5C957D8A87C1'

it gives:

IdTransaction IdDateTime ArchivedDate

70C05AEE-3F2E-BF65-BCF3-5C957D8A87C1 2010-09-06 15:55:39.000 2011-11-04 11:18:00.000

　

I identify the ArchivePointID and VaultID from this idTransaction using :

　

--select fr EVVSEMAILVaultStore2_2.dbo.view_Saveset_Archive_Vault wh IDTransaction Eric Moore BS_1

use EVVSEMAILVaultStore2_2

go

SELECT IdTransaction, ArchivePointId,VaultID FROM view_Saveset_Archive_Vault

INNER JOIN [EnterpriseVaultDirectory].dbo.ArchiveView on ArchivePointId = [EnterpriseVaultDirectory].dbo.ArchiveView.VaultEntryId

--WHERE IdPartition = 0

where IDTransaction ='70C05AEE-3F2E-BF65-BCF3-5C957D8A87C1'

IdTransaction ArchivePointId VaultID

70C05AEE-3F2E-BF65-BCF3-5C957D8A87C1 19CC3B4663B8B7F45A03820FF09EC58C81110000EVSVR1 1F6DC01DA0ECA524AB5E00198719771A81110000EVSVR1

I can't find a way to link it with the VaultStoreEntry or PartitionEntry tables in [EnterpriseVaultDirectory] at this level, though i do have a listing from those tables , joined with Archive, that shows all 10 partitions used by its owner?

[GabeV · Accepted solution]

If you look at the properties of the EV partitions, are they pointing to the new location? This info comes from the PartitionEntry table, Enterprise Vault Directory DB. If you want to confirm that the archived data is being pulled from the new storage location, you can use the EVSVR dumpsaveset command and test as many Savesets as you want:

DumpSaveset command using EVSVR
http://www.symantec.com/docs/HOWTO37697

You will need an archive ID and one saveset ID. If you run a dtrace and add the EVSVR process, one of the steps during the EVSVR dumpsaveset is read the DVS file from storage. In that way, you can confirm if EV is pulling the archived data from the new location.

If you have updated the PartitionEntry table correctly with the new location as the TN states, EV will use that location to extract the archived data. If you want to confirm that ALL the data is on the new location, then EVSVR verify would be the only way, since it would confirm that every single saveset in storage has an entry on the VS and FP DBs and viceversa. Keep in mind that an EVSVR verify against the entire Vault Store will take long time to complete.

I hope this helps.

[GCSPT]

I think you may be chasing tails.

You have migrated physical data from A-B

SQL hasn't changed at all, apart from the RootPath in the Partition Table merely to point it to the new device.

So, all you are really concerned with is whether there is the same amount of data in Destination as Source. Because all SQL references have stayed the same, so no point in really doing anything in SQL.

You need a Storage Compare, plenty of products out there that compare storage.

What is also of a concern is that EVSVR is not giving you comfort (depending on which version) You can run an >Operation>Verify with >Option>complete

"Retrieve the saveset including all of its SIS parts into an Enterprise Vault 8.0 saveset and perform a full verification."

That will run a SavesSetValid Operation which will confirm the existance of the item on storage from the Database reference. As the Database Reference has not moved/been edited that is you point of reliance and as long as the EVSVR comes back with an entry on storage the jobs good.

Hope that gives some clarity, if not a bullet point solution.

[Rem_y]

Thanks guys, in the pursuit of an absolute, I created a blackhole of confusion

I'm going with GabeV's suggestion

Thanks for clearing my head