If you have migrated a registered server to a new server(replacement server), or decommissioned a server, either as a part of your hardware refresh cycle or for disaster recovery purposes, you can use the Server re-registration option to replace or re-add the existing server with the replacement server.
File Server Re-registration
📝 Note
When re-registering a server or host, or restarting a service, do not make any manual modifications to the configuration file folder. These modifications might lead to errors in reactivation, backup, or restore operations.
If you want to make any manual modifications to the configuration file folder, contact Support.
Log in to the Management Console.
Select File Servers from the Protect menu. Note that if the All Organizations menu is enabled, you have to first select an organization that has the server to be re-registered, and then select the workload.
On the Registered Servers page, click the server that needs to be re-registered to view the server details.
On the server details page, click more options, and then click Re-Register Server.
In the Re-Register Server dialog box, click Proceed.
In the Download and Install Agent on the Server section, click Check Pre-requisite to check the Enterprise Workloads agent prerequisites. In the Select OS dropdown, select the operating system of the server where you will install the Enterprise Workloads 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 Management Console on the destination server.
Click Copy Command to copy the activation command for the replacement server activation.
For Windows Server, change the directory to:C:\Program Files\Druva\Phoenix Agent(for agent version prior to 7.0.0)C:\Program Files\Druva\EnterpriseWorkloads(for agent version 7.0.0 and later)
Open Administrative cmd prompt and enter below command:
HybridWorkloadsAgent.exe fs-mssql activate -t <token>(for agent version prior to 7.0.0)
EnterpriseWorkloadsAgent.exe fs-mssql activate -t <token>(for agent version 7.0.0 and later)
Here token value will be the one obtained from step 6.
For Linux server, change the directory to:
cd /opt/Druva/Phoenix/bin(for agent version prior to 7.0.0)cd /opt/Druva/EnterpriseWorkloads/bin(for agent version 7.0.0 and later)
In the terminal, enter the below command:
HybridWorkloadsAgent fs-mssql activate -t <token>(for agent version prior to 7.0.0)EnterpriseWorkloadsAgent.exe fs-mssql activate -t <token>(for agent version 7.0.0 and later)
Here Token value will be the one obtained from step 6.
📝 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.
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 system. Details like server name, agent version, platform of the existing server are replaced with the appropriate details of the replacement server.
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 Hybrid Workloads Agent Client Service / Druva-EnterpriseWorkloads.
Delete the directory:
C:\ProgramData\Phoenix(for agent version prior to 7.0.0)C:\ProgramData\Druva\EnterpriseWorkloads(for agent version 7.0.0 and later)
Uninstall the Enterprise Workloads agent
❗ Important
It is crucial to perform these steps on the original server to avoid any backup failures and conflicts on the new server.
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
📝 Note
When re-registering a server or host, or restarting a service, do not make any manual modifications to the configuration file folder. These modifications might lead to errors in reactivation, backup, or restore operations.
If you want to make any manual modifications to the configuration file folder, contact Support.
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 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.
Log in to the Management Console.
Select MS-SQL Servers workload from the Protect menu. Note that if the All Organizations menu is enabled, you have to first select an organization that has your existing MS-SQL server and then select the workload.
On the Registered Servers page, select the standalone instance hosted on the SQL server that needs to be re-registered.
On the resource details page, in the top right corner, click more options, and click Re-Register Server.
📝 Note:
Servers registered before 16 September 2024 can also be seen on the File Server> Registered Servers page.
In the Re-register Server dialog box, read the message, and click Proceed.
In the Re-register Server dialog box, click Check Prerequisites to ensure that the replacement server meets the hardware and software requirements for the Druva SQL agent.
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 Management Console on the replacement SQL server. Install the agent on the SQL server.
In the Re-register Server dialog box, click Copy token to activate the agent via the Enterprise Workloads agent installer shortcut on the SQL server.
You can also click Copy Command to activate the Enterprise Workloads agent via the command line on the SQL server.
📝 Notes:
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.
If you are using an agent older than version 6.0.1-154928, the following command can be used:
PhoenixActivate govcloud <activation token> --ServerName <Server Name>For agent versions 7.0.0 -7.0.2-526385
EnterpriseWorkloadsAgent.exe fs-mssql activate -token <activation token> --ServerName <Server Name>
For example: EnterpriseWorkloadsAgent.exe fs-mssql activate -token 32931-228-1762-591132241ce4fb2e14fca792cbf532f4a2359eb0bf1b96f82211373ebea7c23b -n WIN-RFE3
For agent versions 7.0.2-537022 and later
EnterpriseWorkloadsAgent.exe mssql activate -token <activation token> --ServerName <Server Name>
For example: EnterpriseWorkloadsAgent.exe mssql activate -token 32931-228-1762-591132241ce4fb2e14fca792cbf532f4a2359eb0bf1b96f82211373ebea7c23b -n WIN-RFE3
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 system. Details like server name, agent version, platform of the existing SQL server are replaced with the appropriate details of the replacement SQL server.
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 Hybrid Workloads Agent Client Service / Druva-EnterpriseWorkloads.
Delete the directory:
C:\ProgramData\Phoenix(for agent versions prior to 7.0.0)C:\ProgramData\Druva\EnterpriseWorkloads(for agent versions 7.0.0 and later)
Uninstall the Enterprise Workloads agent.
❗ Important
It is crucial to perform these steps on the original SQL server to avoid any backup failures and conflicts on the new SQL server.
The recovery points from the existing SQL servers 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.