VBR failing to install Agent for Linux on 1 of many hosts

[kirkhw]

Veeam Backup and Replication 12 is failing Scan/Rescan due to some failed install of Agent for Linux on one of many hosts added to a protection group via a `Add-VBRProtectionGroup` command. All linux hosts are RHEL 8.9 and all successful except for one. The credentials used for all systems have the same permissions.

I'm not confident this target host hasn't previously been managed by this VBR instance and wonder if there is some internal VBR config/state that thinks software exists on the target system (though the directory path is empty).

Is there a way to clear out any left over state/config for this host? (assuming there isn't anything wrong with permissions and the target host)

The log at `C:\ProgramData\Veeam\Backup\Rescan\Rescan_of_<systemName>/Task.<systemName>` gives the following error.

Code: Select all

```
[11.09.2024 18:18:33.835]    <01>    Info (3)    [CLinuxSshPackageUploadStrategy] Linux package '/tmp/veeamdeployment-12.1.2.172-1.x86_64.rpm' successfully deleted from '<systemName>'
[11.09.2024 18:18:33.835]    <01>    Info (3)    Running installation script for /opt/veeam/deployment/veeamdeploymentsvc
[11.09.2024 18:18:33.866]    <01>   Error (3)    Failed to install component (Veeam.Backup.Common.CRegeneratedTraceException)
[11.09.2024 18:18:33.866]    <01>   Error (3)       at Veeam.Backup.Common.CExceptionUtil.RegenTraceExc(Exception originalExc, String formatString, Object[] args)
[11.09.2024 18:18:33.866]    <01>   Error (3)       at Veeam.Backup.ProxyProvider.CLinuxComponentInstallSshUtils.Install(Int32 port)
[11.09.2024 18:18:33.866]    <01>   Error (3)       at Veeam.Backup.Core.ServerCreator.CLinuxPackageInstallationSshStrategy.Install()
[11.09.2024 18:18:33.866]    <01>   Error (3)       at Veeam.Backup.Core.ServerCreator.CLinuxPackageInstaller.InstallComponent()
[11.09.2024 18:18:33.866]    <01>   Error (3)    Unable to invoke /opt/veeam/deployment/veeamdeploymentsvc command because it was not found (System.Exception)
```

[rovshan.pashayev]

Hello,
That sounds like a technical issue. Please provide a support case ID for this issue, as requested when you click New Topic.
Without case number, the topic will eventually be deleted by moderators.

PS: support can only help if you upload logs https://www.veeam.com/kb1832

[kirkhw]

I am working through my CSP's support channel. I thought to see if there was a well known clean up and start again procedure. If the fix is of value I'll post it here.

[kirkhw]

Following the steps below, I was able to get the system in question successfully added, VBR managed installation and scanned through effectively tricking Veeam Backup and Replication by adding the same system with a different hostname (or by IP address). I think this somewhat confirms my suspicion that the VRB database had some belief software was indeed installed on the target Linux host and therefore some service should be listening on port 6160 (i.e. installation of the agent adds a listener to that port). This state may have come to be during a network outage in the middle of an Ansible playbook that executes the Add-ProgectionGroup command.

Please try the following steps:
1. Remove the host from the protection group and re-add with a different name
2. Remove all Veeam software manually from the RHEL device and perform the install via the VBR again. (You've already done this with the uninstall but we'd like you to confirm it with some commands:
------------------
- Confirm /opt/veeam is empty or deleted.
- Verify no Veeam-related services are running (ps aux | grep veeam).
- Remove any leftover configuration files (e.g., /etc/veeam).
- Ensure there are no Veeam-related package residues (rpm -qa | grep veeam).
------------------
3. (OPTIONAL as I simply added under a different hostname) Attempt a manual install of the Veeam Agent for Linux after cleaning up any traces of the previous install.
https://helpcenter.veeam.com/docs/agent ... tml?ver=60

If you see this error again, "Unable to invoke /opt/veeam/deployment/veeamdeploymentsvc command because it was not found", you can check on this with the following command:
check for that: ls -l /opt/veeam/deployment/

You're free to try the reboot as well before trying all of the above to make sure you're working with a clean slate.

[PTide]

Hi,

I think this somewhat confirms my suspicion that the VRB database had some belief software was indeed installed on the target Linux host and therefore some service should be listening on port 6160 (i.e. installation of the agent adds a listener to that port).

Indeed, this could be the case. In such situation I would expect VBR to retry and reinstall veeamdeploymentsvc.
Will check with our development team on that.

Anyway, thank you for sharing the method!

Cheers