Problem Description
Backups for File Servers, Hyper-V, and SQL Servers in Druva Phoenix may fail with error code PHOENIX189 if the servers have been migrated to new hardware while the old servers are still running the Druva agent.
Cause
When a server is registered with Phoenix, it is assigned a unique device ID for identification.
If a server is migrated to new hardware but the original machine is still running the Druva agent, both servers will share the same device ID. This creates a device ID conflict, preventing backups from completing successfully.
Traceback / Error Message
Backup logs may include errors such as:
Error validating server certificate : (10054, 'WSAECONNRESET')
The session is invalid. (#10000006e)
Failed (Error Code : PHOENIX189)
[2020-02-20 05:07:52,773] [ERROR] Error <class 'inSyncLib.inSyncError.SyncError'>:
Dropped network connection. (#100000022) (Error Code : PHOENIX34)
Example from logs:
Traceback (most recent call last):
File "roboSyncController.py", line 312, in start_command_server
File "roboSyncController.py", line 325, in _start_command_server
File "inSyncLib/inSyncRPCServer.py", line 577, in serve
File "inSyncLib/inSyncRPCServer.py", line 212, in serve_forever
File "inSyncLib/inSyncRPCServer.py", line 231, in process_requests
File "inSyncLib/inSyncRPCBase.py", line 1094, in handle_request
File "inSyncLib/inSyncRPCBase.py", line 852, in _issue_request
File "inSyncLib/inSyncRPCBase.py", line 860, in __wait_response
SyncError: Dropped network connection. (#100000022) (Error Code : PHOENIX34)
Resolution
To fix this issue, follow these steps:
Stop the Druva Agent Service on the Old Server
Open services.msc
Stop the Druva/Phoenix service
Rename the Old Phoenix Directory
Pre-7.0.x versions:
C:\ProgramData\Phoenix → rename to Phoenix_old7.0.x and later:
C:\ProgramData\Druva\EnterpriseWorkloads → rename to EnterpriseWorkloads_old
Generate a Re-registration Token & Activate the Agent
In the Druva Console, create a new activation token for the new server.
Follow the re-registration process documented here:
Hyper-V: Hyper-V Host Re-registration
FS/SQL: Server Re-registration
Verify and Test Backups
Confirm in the Druva Console that the new server is registered and connected.
Run a test backup to ensure it completes successfully.
Additional Notes
Always stop and rename the old agent directory before registering the new server to avoid conflicts.
For environments with both SQL and File Server agents, unregister only the required workload to prevent accidental data removal.
If re-registration fails, ensure the old device entry is removed from the Druva Console before retrying.