Rescan operation fails when adding a server to a Protection Group in RHEL 6.6.
I am currently trying to backup 2 physical servers with Veeam. The target servers are running RHEL 6.6 (2.6.32-504.1.3.el6.x86_64). When I try to include them in a Protection Group to create a backup job, I am encountering an issue where one server succeeds and the other fails.
In the Veeam Console UI, it shows up as failed with the message "The server has closed the connection." When checking the log related to the Rescan Task, the main error message is "Failed to upload package file from "D:\veeam\Backup\Packages\veeamdeployment-12.2.0.334-1.x86_64.rpm" to "/tmp/veeamdeployment-12.2.0.334-1.x86_64.rpm". Timeout: 10800 sec, mode: 644 (Veeam.Backup.Common.CRegeneratedTraceException)".
It seems unrelated to the fact that the file upload to the server is not possible. This is because the situation is as follows:
- Use root account when backing up Veeam - Veeam backup server and backup target server are located on the same network - SELinux and firewall are both disabled on the target server - No permissions or ownership issues with /tmp (nothing unusual in other servers or SCP test results)
I tried reinstalling Veeam Agent manually or installing the veeamdeployment file above, but the Protection Group addition fails due to certificate issues, etc.
I would appreciate your help.
*Â I have attached the rescan log and changed all IPs of the target servers to "TARGET SERVER".
Redeploy the agent and ensure the certificate is accepted.
Â
Check if all libraries are up to date by comparing them on the server that is running, ---> glibc gcc libgcc , or also update them ssh.
yum install -y glibc gcc libgcc
we await updates
I doubt it’s about a timeout, sorry to disagree.
From the log:
p23.12.2024 16:24:41.045] Â Â <01> Â Â Info (3) Â Â 3Ssh] Creating new connection f6563d52-54d6-4552-9a1e-b41773b3e40e 3host: 'TARGET SERVER', port: 22, elevation to root: 'no', autoSudo: no, use su if sudo fails: no, host name: TARGET SERVER, IPs: RTARGET SERVER], AuthenticationData: oUserName: root, AuthTypes: hKeyboardInteractive, Password]]]
«truncated for readability»Â
Â23.12.2024 16:24:56.339]   <01>   Info (3)   LinuxManagedPackageInstaller] Uploading the package t23.12.2024 16:24:56.343]   <01>   Info (3)   gUploadManager] Uploading linux package 'veeamdeployment-12.2.0.334-1.x86_64.rpm' 323.12.2024 16:24:56.403]   <01>  Error (3)   Failed to upload file D:\veeam\Backup\Packages\veeamdeployment-12.2.0.334-1.x86_64.rpm to /tmp/veeamdeployment-12.2.0.334-1.x86_64.rpm "23.12.2024 16:24:56.403]   <01>  Error (3)   The server has closed the connection. (Rebex.Net.ScpException) e23.12.2024 16:24:56.403]   <01>  Error (3)    위치: mwgvd.ymphv.wwrbt(Boolean p0) ì23.12.2024 16:24:56.403]   <01>  Error (3)    위치: Rebex.Net.Scp.bwyfn(String p0, String p1, Stream p2, Int64 p3, ypfpi p4) g23.12.2024 16:24:56.403]   <01>  Error (3)    위치: Rebex.Net.Scp.yfukn(String p0, String p1, Int64 p2, ypfpi p3) x23.12.2024 16:24:56.403]   <01>  Error (3)    위치: Veeam.Backup.SSH.RebexLib.CSshRebexScpFileLoader.UploadFileImpl(String from, String to, Boolean needToElevate, String mode, IFileLoaderOptions fileLoaderOptions)
Â
Less than a second passes before the connection is closed from the remote server.
Try the steps here, though i’m doubtful it’s about this. For reference, Veeam in current version will try to use one of three .NET SSH Libraries for SSH connections:
Granados => Very old library, almost certainly no modern system (post 2015? loose date here) will use it and it likely will never work. Kept for legacy systems that require it. Can almost guarantee you can ignore all Granados related errors, they’re almost certainly expected.
Renci => Probably the most common one that will work for most people
Rebex => Newest one, most secure of the three, but the security hardening sometimes is not compatible with other hardening.
Anyways, give the KB a shot, and if it won’t go, open a Support Case for the issue: https://veeam.com/1771.
Sorry for the late update.
​@Link StateÂ
Check the server-side SSH Timeout: Check sshd_config → It doesn’t work.
Is there disk space in /tmp?
→ /tmp has sufficient capacity.
Can you check the installation logs on the target server?
→ The log file itself does not exist.
can you try remove cert cache
→ The certificate also doesn't exist.
Check if all libraries are up to date by comparing them on the server that is running, ---> glibc gcc libgcc , or also update them ssh.
→ The file list is as follows:
→ RHEL 6.6 has become EOS, so it cannot be installed using yum. Are there any packages I need to install from the following list?
Â
​@ddomaskÂ
I tried the solution according to the Veeam KB, but I could not find the tmux-related settings, perhaps because the server where the problem occurred was RHEL 6.6. I created and ran the fapolicyd script and tried Rescan, but the same problem occurs.
Â
Got it, thanks for the efforts. I would open a support case at this stage and let Support take a look. Probably this will not be solvable over forums alone.
​@ddomaskÂ
Thank you for your concern.
The issue was resolved using a workaround.
Since you told us that there were problems with the SSH method, I decided to use a method that does not use SSH.When registering the backup target server, I tried registering it based on a certificate.
After registering using the certificate method, the backup target server was registered and the Rescan operation was possible. And as a result of today's confirmation, the backup job has also been completed.