Skip to main content

How can we help you?

Druva Documentation

Server re-registration

If you have migrated a registered server to a new server(replacement server), or decommissioned a server in Druva Phoenix, either as a part of your hardware refresh cycle or for disaster recovery purposes, you can use the Server re-registration option to replace the existing server with the replacement server in Druva Phoenix.

File Server Re-registration

  1. Log in to the Phoenix Management Console.
  2. On the menu bar, click All Organizations, and then select the organization that has the server to be re-registered.
  3. On the menu bar, click Protect > Windows/Linux servers.
  4. On the Registered Servers page, click the server that needs to be re-registered to view the server details.
  5. On the server details page, click more options, and then click Re-Register Server.
  6. In the Re-Register Server dialog box, click Proceed.
  7. In the Download and Install Agent on the Server section, click Check Pre-requisite to check the Phoenix agent prerequisites.  In the Select OS dropdown, select the operating system of the server where you will install the Phoenix agent, and then click Download. The agent download begins on the same browser page. The agent is not downloaded on the destination server unless you click Download through the Phoenix Management Console on the destination server.

    Re-register new server.png
     
  8. Click Copy Command to copy the activation command for the replacement server activation.
    Note: The replacement server must be activated with the activation token generated at this stage. Activating with any other activation token will register the replacement server as a new server with Druva Phoenix.
  9. After the agent is installed on the replacement server and it is activated with the token provided in the Re-Register New Server dialog box, the replacement server assumes the identity of the existing server in the Druva Phoenix system.  Details like server name, agent version, platform of the existing server are replaced with the appropriate details of the replacement server. 
  10. If the original and new server are separate servers (not the same server) and both servers are online, perform the following tasks on the original server
    • Stop the Druva Phoenix Service 

    • Delete the  C:\ProgramData\Phoenix directory

    • Uninstall the Phoenix agent 

       It is crucial to perform these steps on the original server to avoid any backup failures and conflicts on the new server.

  11. The restore points(snapshots) from the existing server can be viewed in the restore wizard of the replacement server and restores can be triggered from the restore wizard of the replacement server.

Note: Re-registration does not restore the non-default configuration parameters that might have been configured for the original server. Administrator must freshly configure these parameters after reactivation.

SQL Server Re-registration 

Use the Re-Register SQL Server option to replace a registered SQL server that hosts a standalone SQL instance with a replacement server in the Phoenix Management Console. You can use this option when you need to migrate a registered SQL server to a replacement server as part of a hardware refresh or disaster recovery. 

Note: The Re-Register option is only available for standalone SQL instances currently.

  1.  Log in to the Phoenix Management Console.
  2. On the menu bar, click the drop-down next to All Organizations and select the organization that has your existing MS-SQL server.
  3. On the menu bar, click Protect > MS-SQL Servers.
  4. On the All SQL Resources page, click the standalone instance hosted on the SQL server that needs to be re-registered.
  5. On the resource details page, in the top right corner, click more options, and click Re-Register Server.

    Re-register server.png
  6. In the Re-register Server dialog box, read the message, and click Proceed.

  7. In the Re-register Server dialog box, click Check Prerequisite to ensure that the replacement server meets the hardware and software requirements for the Druva Phoenix SQL agent.

    Re-register server wizard.png

  8. Download the Windows 64-bit SQL agent, and install it on the replacement SQL server. The agent download begins on the same browser page. The agent is not downloaded on the replacement SQL server unless you click Download through the Phoenix Management Console on the replacement SQL server. Install the agent on the SQL server.

  9. In the Re-register Server dialog box, click Copy token to activate the agent via the Phoenix agent installer shortcut on the SQL server.

    Re-register server- Copy token.png
    You can also click Copy Command to activate the Phoenix agent via the command line on the SQL server.

    Re-register server- Copy Command.png

Note: The replacement SQL server must be activated with the activation token generated at this stage. Activating with any other activation token will register the replacement server as a new SQL server in Druva Phoenix.

  1. After the agent is installed on the replacement server and it is activated with the token provided in the Re-Register Server dialog box, the replacement server assumes the identity of the existing server in the Druva Phoenix system.  Details like server name, agent version, platform of the existing SQL server are replaced with the appropriate details of the replacement SQL server. 

  2. If the original and new server are separate servers (not the same server) and both servers are online, perform the following tasks on the original server: 

    1. Stop the Druva Phoenix Service.

    2. Delete the  C:\ProgramData\Phoenix directory.
    3. Uninstall the Phoenix agent

 It is crucial to perform these steps on the original SQL server to avoid any backup failures and conflicts on the new SQL server.

  1. The restore points(snapshots) from the existing SQL server can be viewed in the restore wizard of the replacement SQL server and restores can be triggered from the restore wizard of the SQL replacement server.

Note: Re-registration does not restore the non-default configuration parameters that might have been configured for the original server. The administrator must freshly configure these parameters after reactivation.

  • Was this article helpful?