cancel
Showing results for 
Search instead for 
Did you mean: 

Symantec Enterprise Vault for Exchange 2007

unifiedstorage
Level 2

Hi

The Exch 2007 stores are moved to new unified storage and the host that holds the Symantec Enterprise Vault must also be moved into new LUNs on the new storage.

I know that I can use copy or restore tools to do this, but I want tips or a better solution / online migration

 

Regards

KLP

1 ACCEPTED SOLUTION

Accepted Solutions

Jeff_Shotton
Level 6
Partner Accredited Certified

I don't think you are going to get away without doing some sort of very brief service restart. I would always advise scheduling plenty of downtime to do this carefully. However if you are feeling gung-ho, read on.

If you want to keep downtime to a minimum, and you do not have the capability to natively replicate storage from one source to another (SRDF for instance) then make sure you have set the environment so that no user changes or collection runs can be made as per the pre-migration steps in the following document:

http://www.symantec.com/docs/TECH141481

Then, create a new partition on the new LUN so that new archived data is going to be going to use this going forwards.

As the old partitions are now effectively read-only because you have

a) disabled user updates and

b) disabled the collections process

(ok items may be extracted from Cabs but this is not an issue)

then you can go ahead and update the vault store partition database. Prepare a script for this so it can be done in ultra-fast time. You *could* even (ultra cowboy mode) do this whilst the environment is still running because the storage would be available in both locations. You would need to restart storage to confirm the new locations were in use though.

For indexes,

set them to read-only.

replicate the data over.

Switch the locations in the database

restart indexing. remove read-only

If the index is out of date it will catch up, so the only thing that could *possibly* happen is that half the files in an index were being updated at the time of a copy, and that isn't going to happen because they were in read-only.

Back out your read-only changes, and you are done.

Regards,

Jeff

 

View solution in original post

6 REPLIES 6

ZeRoC00L
Level 6
Partner Accredited

You can use normal copy tools like robocopy.

Make sure to stop the EV services, copy the data to the new volume(s).
Dismount the old volume(s).
Mount the new volume(s) with the same driveletters as the old one(s).
Start EV services.

unifiedstorage
Level 2

Thanx for the reply, but this I know.

I need tips on how to do this online :)

Jeff_Shotton
Level 6
Partner Accredited Certified

I don't think you are going to get away without doing some sort of very brief service restart. I would always advise scheduling plenty of downtime to do this carefully. However if you are feeling gung-ho, read on.

If you want to keep downtime to a minimum, and you do not have the capability to natively replicate storage from one source to another (SRDF for instance) then make sure you have set the environment so that no user changes or collection runs can be made as per the pre-migration steps in the following document:

http://www.symantec.com/docs/TECH141481

Then, create a new partition on the new LUN so that new archived data is going to be going to use this going forwards.

As the old partitions are now effectively read-only because you have

a) disabled user updates and

b) disabled the collections process

(ok items may be extracted from Cabs but this is not an issue)

then you can go ahead and update the vault store partition database. Prepare a script for this so it can be done in ultra-fast time. You *could* even (ultra cowboy mode) do this whilst the environment is still running because the storage would be available in both locations. You would need to restart storage to confirm the new locations were in use though.

For indexes,

set them to read-only.

replicate the data over.

Switch the locations in the database

restart indexing. remove read-only

If the index is out of date it will catch up, so the only thing that could *possibly* happen is that half the files in an index were being updated at the time of a copy, and that isn't going to happen because they were in read-only.

Back out your read-only changes, and you are done.

Regards,

Jeff

 

ZeRoC00L
Level 6
Partner Accredited

Online will not be possible, but you can copy the data already to the new volume, then stop EV, and change the volumes. This will limit the downtime to a few minutes.

Make sure no archiving is done during the copy, otherwise you will have to resync the data when EV is stopped!

Rob_Wilcox1
Level 6
Partner

If users aren't allowed to do any deletes, and you don't have storage expiry running, and you set the mailbox archiving schedule to 'never' (assuming we're talking about Exchange mailbox archiving here?) then the only additions to the data partitions will be users manually archiving data.

 

Therefore you could experiment with the following ...

 

Copy all your data, eg Hundreds of Gb.

Wait for an agreed upon maintenance window when you're going to do the switchover.

Do a final 'file compare' type of operation (when any 'new' bits of data will be picked up)

Switch over.

 

That has legs, and can run ...  I think?

Working for cloudficient.com

unifiedstorage
Level 2

Thanx guys

I will give this link to the vault adm. He must give me new input regarding youre reply`s yes