8 Replies Latest reply: Mar 1, 2012 3:55 AM by Dmitry Abramson RSS

Moving RecoverPoint 3.2 to new array


Hi all,


I've got tree array on a primary location, two CX500 array and one CX4-240 array and RecoverPoint 3.2 Installation running on a Clariion CX500 using the array splitter on a CX4-240 array. First CX500 array has some hardware issues and I must move RecoverPoint on second CX500 array. I cannot find documentation for how to do this.


There are some steps that I recorded: 


1. Backup Repository volume with save_settings and save_account settings commands,

2. Disable all CG's,

3. Detach all RPA's at the site where the array is changing,

4. Zone RPA's and second CX500 array,

5. Connect RPA's to a new array,

6. Format the new repository,

7. Select this new repository and attach all RPA's to new repository,

8. Restore Repository volume,

9. Enable all CG's.


I'm missing someting? What is the deal with license?


Thank You

  • 1. Re: Moving RecoverPoint 3.2 to new array
    Dmitry Abramson

    Since you want to backup the repository, I assume it's on CX500 array?  Which splitters are you using on CX500s?

  • 2. Re: Moving RecoverPoint 3.2 to new array

    Yes, repository volume is  on CX500 array. I'm using Clariion splitter on CX4-240 array.

  • 3. Re: Moving RecoverPoint 3.2 to new array
    Dmitry Abramson

    I just want to make sure I understand the configuration, because it is a little unusual.  You are replicating LUNs off CX4-240 only and are using CX500 for a 2.86G repository volume?  And you would like to migrate that 2.86G repository volume to another CX500?  Why not migrate it to CX4-240 with the rest of your LUNs?  If you only have one CLARiiON array per site, you can actually switch to RP/SE license and potentially save money.


    Assuming you just want to move a repository from one array to another, your procedure is correct.  If you have two sites, you will get a repository conflict between the sites and you can just choose the repository information from the "good" site.


    In terms of licensing, the installation ID is dependant on the repository LUN UUID.  When you choose another repository, UUID will change, the installation ID will change and you will need to get a new activation code.  However, the license itself can stay the same.

  • 4. Re: Moving RecoverPoint 3.2 to new array

    Hi Bosko,


    Basically you are just moving the Repository volume from the CX500. Can I suggest that you move it to the CX4 array and not to the other CX500.


    All steps are valid. If you had a CRR config and a remote array you could pull the config into the new Repository volume from that side of the cluster.


    You will have to re-license due to the new Repository and the change to the Installation ID based on the UUID of the new Repository volume. Use the get_account_settings CLI command or screen capture of the the Account Settings to assist you with this.





  • 5. Re: Moving RecoverPoint 3.2 to new array
    Ernes Taljic

    RP on CX array splitter is not supported. RP only support CX3, CX4 and VNX arrays with array splitters. What splitter are you using on the CX500 array?

  • 6. Re: Moving RecoverPoint 3.2 to new array

    Yes, I'm replicating CX4-240 LUN's only but in the past some Solaris production hosts has been connected to the CX500 array. RecoverPoint migration to second CX500 array is the customer suggestion but I also meen that is better solution to migrate RecoverPoint repository volume on CX4-240 array. Afther short discussion with a customer they are decided to migrate all production hosts and volumes to a CX4-240 array. In that case RecoverPoint will bi migrated on CX4-240 and CX500 array will contain CDP replica of production volumes.


    Yes, I've two sites. All changes will be on a primary site. RecoverPoint configuration on remote site is not changing. Which is ''good'' site?

  • 7. Re: Moving RecoverPoint 3.2 to new array

    Host based splitters are used on CX500 array.

  • 8. Re: Moving RecoverPoint 3.2 to new array
    Dmitry Abramson

    The repository is stored at both sites.


    Since you are formatting the repository on the primary site, the "good" site will be the secondary site.  When you choose a new repository at the primary site, you will have a site conflict: primary site will be empty and secondary site will have the good copy of the pre-migration repository.  You can then resolve the conflict by choosing the secondary site as a winner.


    You should still save a repository backup using save_settings command, in case something goes wrong.