How to migrate Rapid Recovery Core installation to a new server (4040779)

Migration of the Core to the new server is a multi-step process, which requires several preparation steps:

• Where is the current repository is located? Is it locally attached (DAS), network-attached (SAN or NAS)?
• Does the repository having multiple extensions?
• Does the new Core machine having enough space for the repository, if repository is going to be copied over (for DAS)?
• If repository is networked, can the new Core communicate with it?
• Are encryption keys used for backups?
• Does current Core having replication links?
• Are there Virtual Standbys or any other schedules jobs like scheduled archival?
• Any custom protection schedules for the agents?

The process of migration consist of these steps:

1. Save the Rapid Recovery Core configuration data, list of protected agents, export encryption keys. Delete replication links.
2. Shut down the original Core service.
3. Set up new Core server, download license (LIC file) from rapidrecovery.licenseportal.com, and apply it to the new Core. You will be prompted to apply the license the first time you open the Core Console after install.
4. When you restore the saved Rapid Recovery Core configuration data, make sure to replace the old host server with the new host server name.  This can be done by editing the backup.xml file created or within the registry.
5. To edit registry keys: 

   Navigate to HKLM\SOFTWARE\AppRecovery\Core\CoreSettings
   Notice the value the String key DisplayName has, and edit it to give it the core's correct hostname

   Navigate to HKLM\SOFTWARE\AppRecovery\Core\VMProxy
   Look at the string key HostAddress and edit its value to have the core's correct hostname.

6. Repository locations:
   1. For DAS repository, copy all repository extension folders to the new Core.
   2. For network-attached storage, make sure that new Core can access NAS Share or map the iSCSI target.
7. Import encryption keys.
8. From the new Core, click on More, Repositories, Open existing DVM repository and point to the copied/networked repository. Fix paths if needed.
9. After the repository went through the maintaining process, re-protect all agents, setting the protection schedules accordingly.
10. Re-create replication links, virtual standby, scheduled archives (if applicable).

Alternatively, Core can be migrated to another Core using replication method. This is especially helpful if the old repository is having a long usage history and/or having multiple extensions that could be combined into one on the new Core. Also helpful if the original repository is having low compression and deduplication ratios. Also, this method is a least production-impacting one since the old Core will keep doing backups while data is migrated.
The process of migration will be as following:

1. Install the new Core server which is adequately sized in terms of RAM, CPU and storage resources.
2. Create a new repository on the new Core. Please attempt to expand More Options while adding new storage location and turn off Write Caching if possible. Write Caching off requires that disks are using 512 bytes per sector unit allocation. This can be checked through MSINFO32, Components, Storage, Disks section.
3. Go to Settings, DVM Deduplication Cache and increase it from the standard 1.5GB using this formula: 1GB of DVD Dedupe per 1TB repository size. However please consider those rules: DVM dedupe should not be bigger than 1/2 of physical RAM on the Core server. Also, realistically there's not much sense increasing DVM dedupe size bigger than 10GB.
4. Go to More (...), Retention Policy and set it equal to the retention policy of the old Core.
5. On the old Core setup replication to the new Core.
6. Please make sure per each agent, More dropdown, Retention Policy if agent is using Core global or custom retention policies. Custom retention policy is taking precedence over a global one and replication may rebuild RP chain on the fly, skewing the replication process. If custom Retention Policy is used, the same policy must be set on the new Core. Also, if data was already replicated using nonmatched policies, then agent's data need to be deleted on the new Core, policies set to exactly the same and replication should be started over.
7. Wait until replication is done and no more replication jobs are happening. Replication may still happen as the old Core takes snapshots.
8. Pause protection for all agents on the old Core. Compare Recovery Points number for each agent on both Cores to make sure that all data was migrated. Force replication job for specific agent if there are discrepancies.
9. Export all encryption keys on the old Core to separate files.
10. On both Cores go to Replication icon and delete incoming/outgoing replication links between them.
11. Import encryption keys on the new Core.
12. Re-protect all agents on the new Core taking agents' ownership from the old Core.
13. Re-create replication links, virtual standby, scheduled archives (if applicable).