EV8 Managing Indexing locations and vault locations

[EVMan]

Hi

We have recently upgraded to EV8, and want to make full use of the rollover partitions etc.

MAILBOX & JOURNAL PARTITIONS

We have our journal and mailbox partitions sat on an EMC Celerra, the KVS environment is running on Virtual Machines on VMWare ESX 3.5. Connectivity tests in the storage groups between the KVS servers and partitions return 'Good' so we are happy to leave these where they are. Currently we are holding partitions of around 2yrs each for Journal and Mailbox. The backup window is coping with this but should we look to split this down to quaterly rollovers to manage them better and make it easier to move the data in future? With the moving of this closed data can you just use robocopy over the weekend when KVS is in backup mode; or should you use the migration tab which is new in EV8 with the partitions? Has anyone done any testing with this built in migration of closed partitions and does it provide much over-head on the KVS Servers? And should Journal and Mailbox vault partitions ultimately sit on different storage or does it not really matter?


INDEXES

I understand its best practice to have 8 open locations for indexes. At the moment these are also sat on the EMC Celerra too, so i think they would be better suited to sit these on VMFS storage presented to the KVS VM's for quicker access as well as create a cache location local to the VM too of around 20Gb? It doesn't seem that you can do rollover of index locations with EV8 which is fine. So could i close of these index locations and create 8 new index locations locally? (8 for mailbox archive server and 8 for journal archive server); However if i want to edit the location of the closed index locations then how do you do this?! And can these closed index locations be moved off to different storage without disturbance once KVS is writing to the new locations locally to the VM?

Apologies for calling EV -  KVS in this post!

thanks
James

[MichelZ]

James

MAILBOX & JOURNAL PARTITIONS

You can use robocopy without EV in backup mode.
Then use robocopy again with EV Services down or in Backup mode to copy the delta over..
Closed partitions should not provide overhead at all if you have shared partitions.
I'd recommend rollover by Gigabytes instead of age, but that's just my preference to have manageable "junks" of partitions for backup purposes.
The migration tab actually does not "migrate" the data in the way you think. It does migrate data to secondary storage like tape, which is generally a bad idea. (Just think about a Vault Cache rebuild where data is stored on tape.....)

INDEXES

Your current indexes won't "close" the same way as the partitions do.
When you close an index location, it means that Enterprise Vault does not create new indexes on this index location, but it will update already existing indexes. (You will have an index per archive), so you can't split a single archive index over multiple locations, and your closed index location is still used actively.

This means you would have to manually move the existing indexes (files), and then set the new index location in the VAC.

Hope this helps.
Cheers

[EVMan]

Hi

Thanks for the reply - that helps alot we will use robocopy to do migrations.

So if we were to keep our vault paritions on our EMC Celerra (we use DFS to easily move the shares around too) ; would it be worth moving the indexes locally to the EV Server for better performance or not? Certainly from my reading we should think about setting up a cache location locally to the EV servers (VAC, EV Servers, EVServer props, Cache tab) ?

And as far as the 'connectivity test facility' which is available on the vault store group in EV8 goes - is 'Good' generally good or is there an 'excellent' which it can go to to test perfromance of the storage / EV servers?!

Thanks again
James