TL,DR
After upgrading to Veeam Backup and Replication v13, in one of our customer environments SAP HANA application backups started failing because the plug in tried to reach the repository on TCP 6162 first, timed out, and did not automatically fall back to the classic 2500 to 3300 range in our scenario as it should have done according to documentation.
Opening 6162 fixed the connectivity requirement as confirmed by Veeam Support.
Our issue
Backups that had been stable on v12 suddenly failed right after moving to v13, specifically SAP HANA application backups using the Veeam Enterprise plug in for SAP HANA.
Symptom
Our HANA jobs spent a long time “trying to connect” and then died with a timeout. In the logs it was obvious that the plug in was repeatedly attempting to connect to the repository IP on port 6162 and eventually timing out.
[27.03.2026 13:17:37.846] <139893376276160> plugin_co| IP endpoints: [10.211.102.158:6162; 10.211.102.158:2501].
[27.03.2026 13:17:37.846] <139893376276160> | Trying to connect to the endpoint [10.211.102.158:6162][27.03.2026 13:23:54.662] <139893376276160> | Connection status: system:110 ( Connection timed out ).
Relevant log excerpt shows the endpoint list including 6162 and a port in the old range, then the attempt on 6162, then timeout.
What we expected, based on Veeam’s documentation
Coming from v12, we had the classic data mover range 2500 to 3300 already opened, because it had been mandatory for various data paths in many environments. That led to the natural assumption: worst case it should still work with the known port range and 6162 might be “nice to have”.
This fall-back behavior is even stated in helpcenter as of today:
Of course we checked that before the update and assumed to fine because of what is stated in the documentation. But it turns out not to be correct in that case.
What is confirmed / Take home message
With V13 Veeam started a process to massively reduce the number of ports used for connecting all the distributed modules and parts of the application, which in general is pretty good news. No one likes the massive firewall preparation lists in network-wise highly isolated environments.
Here e.g. we see a reduction from a whole range of ports (2500-3300) to a single one (6162). Obviously, it was planned to be backwards compatible, still falling back to the old range if 6162 is not available.
Reviewing the logs we determined that this was not implemented like that. After giving it a try with additionally opening 6162 for the connection between the plug in machine and the repository. Then we reran the backup and everything was fine again.
My recommendation is, if you happen to face issues after a migration to a newer version, always give it a try with the new port options, even if the old ones should still work.
As we’re facing a lot lot of changes here, there can always be issues in the implementation of the fallback process. I’d expect helpcenter to be corrected here, or maybe fallback will work in the next patch.