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

How to migrate Rapid Recovery Core installation to a new server

The Rapid Recovery Core needs to be migrated to a new server while preserving all data, minimizing downtime, and ensuring compatibility.

There are several reasons why you may need to start running the Rapid Recovery Core software on a different server. This could be due to hardware failure, server upgrades, consolidation of resources, or the need for a more powerful server to support the Rapid Recovery Core software. It may also be necessary to migrate to a new server to take advantage of improved hardware or software capabilities. Whatever the reason, it is important to ensure that the migration process is done carefully to avoid data loss and minimize downtime.

Migrating the Rapid Recovery Core to a new server is a multi-step process that requires careful preparation to ensure a successful transition. Before starting the migration, it is essential to consider various factors such as the current location of the repository, whether encryption keys are used, and the presence of replication links, virtual standbys, and any custom protection schedules.

The migration process can be done in two ways: by copying the repository to the new Core server or by using the replication method. The replication method is recommended for repositories with a long usage history, multiple extensions, or low compression and deduplication ratios.

For the repository copying method, the following steps should be followed:

1. Save the Rapid Recovery Core configuration data, list protected agents, and export encryption keys. Delete replication links.
2. Shut down the original Core service.
3. Set up the new Core server, download the license (LIC file) from rapidrecovery.licenseportal.com, and apply it to the new Core.
4. Edit the backup.xml file created or within the registry to replace the old host server with the new host server name.
5. Copy all repository extension folders to the new Core for the DAS repository or make sure the new Core can access NAS Share or map the iSCSI target for network-attached storage.
6. Import encryption keys.
7. Open the existing DVM repository from the new Core, point to the copied/networked repository, and fix paths if needed.
8. Re-protect all agents and set the protection schedules accordingly.
9. Re-create replication links, virtual standby, and scheduled archives if applicable.

For the replication method, the following steps should be followed:

1. Install the new Core server with adequate resources.
2. Create a new repository on the new Core and increase DVM Deduplication Cache if necessary.
3. Set the retention policy equal to the retention policy of the old Core.
4. Set up replication to the new Core from the old Core.
5. Check each agent's retention policy and set the same policy on the new Core if a custom retention policy is used.
6. Wait until replication is done, and no more replication jobs are happening.
7. Pause protection for all agents on the old Core and force replication jobs for specific agents if there are discrepancies.
8. Export all encryption keys on the old Core and delete incoming/outgoing replication links between the Cores.
9. Import encryption keys on the new Core, make sure the encryption key is changed to "Universal" type, and re-protect all agents, taking agents' ownership from the old Core.
10. Re-create replication links, virtual standby, and scheduled archives if applicable.

It is recommended to follow the steps carefully and thoroughly test the migrated system and validate the data integrity before transitioning to the new server.