Forum Discussion

unifiedstorage's avatar
unifiedstorage
Level 2
12 years ago

Symantec Enterprise Vault for Exchange 2007

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

Best Practice
Enterprise Vault
Information Governance
Upgrade
  • Jeff_Shotton's avatar
    Jeff_Shotton
    12 years ago

    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

     

6 Replies

Sort By
  • ZeRoC00L's avatar
    ZeRoC00L
    Level 6
    12 years ago

    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.

  • Jeff_Shotton's avatar
    Jeff_Shotton
    Level 6
    12 years ago

    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's avatar
    ZeRoC00L
    Level 6
    12 years ago

    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's avatar
    Rob_Wilcox1
    Level 6
    12 years ago

    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?

  • unifiedstorage's avatar
    unifiedstorage
    Level 2
    12 years ago

    Thanx guys

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