Problem description
In some situations, the server connection between the Phoenix file server agent and the Phoenix cloud may become inconsistent. The backups may fail in such cases, and the latest recovery points may not be healthy. This may happen when administrators install the Phoenix file server agent inside VMware virtual machines to protect specific files, folders, or volumes during backups.
Cause
You may run into this issue when the file server in question is a VMware virtual machine that was cloned from a server where the Phoenix agent was installed. The original file server machine and the cloned virtual machine coexist in your environment. The file server agent on both the original server and the cloned VM try to establish a connection with the Phoenix cloud, thereby creating a conflict. Your VMware administrator or System administrator can help you determine if the original server was cloned or not.
Resolution
Option 1: Uninstall the Phoenix file server agent from the clone VM
Identify the clone VM and log in to the guest OS of this VM.
Uninstall the Phoenix file server agent from this VM. Follow the instructions as per the operating system of the clone:
Once the file server agent has been uninstalled from the clone VM, login to the original file server machine and perform the following tasks:
Stop the Druva Phoenix Agent Service.
Navigate to the following location and rename all the
*.dbfiles.Windows:
C:\ProgramData\Phoenix\FS\state\backup\<backupsetid>\*.dbLinux:
/var/Phoenix/FS/state/backup/<backupsetid>/*.db
Once the files have been renamed, restart the Druva Phoenix agent service.
Go to the Phoenix Management Console and navigate to the original file server. Make a small dummy change to the content rule for the backup set of this file server. You can include or exclude some data and update the content rule. You can revert this change once the content rule has been saved.
Initiate a manual backup ( Backup Now) of the original file server. This will ensure that the backup of the original server is successful.
Option 2: Configure the clone VM as a new Phoenix file server
If you want to protect the clone VM then you can configure it as a new Phoenix file server. As a new Phoenix file server it can coexist with the original file server machine.
Identify the clone VM and log in to the guest OS of this VM.
Uninstall the Phoenix file server agent from this clone VM.
Windows: Uninstall Phoenix agent from Windows
Follow the instructions in the Install the agent and register a server article to download the Phoenix agent for file servers, install it on the VM, and register the VM as a new server in the Phoenix Management Console.
Log in to the original file server and perform the following tasks:
Stop the Druva Phoenix Agent Service.
Navigate to the following location and rename all the
*.dbfiles.Windows:
C:\ProgramData\Phoenix\FS\state\backup\<backupsetid>\*.dbLinux:
/var/Phoenix/FS/state/backup/<backupsetid>/*.db
Once the files have been renamed, restart the Druva Phoenix agent service.
Go to the Phoenix Management Console and navigate to the original file server. Make a small dummy change to the content rule for the backup set of this file server. You can include or exclude some data and update the content rule. You can revert this change once the content rule has been saved.
Initiate a manual backup ( Backup Now) of the original file server. This will ensure that the backup of the original server is successful.