Ports required for File-Level restore Windows and Linux OS

[prabhash.jena]

Hi,

I need to know the exact ports required\used between Backup\Mount servers and target VM (customer subnet) for file-level restore.

We are a MSP. Our backup infrastructure servers (Management\Proxy\Repository etc.) are in an isolated IPv6 network. I know IPv6 is not used by Veeam (not sure why?).
Our backups are very snappy however guest file restores are very slow. Restore speed doesn't go over 500 KB\s. I believe it’s because backup\mount servers doesn't have access to the subnet to which file restore is being done. I would like to know the exact ports required\used between backup servers (Veeam Managed Servers) and target VM (customer subnet). Our Network admin is adamant (due to security threats) and doesn't want to open up whole network channel.

Also please share if you have any suggestions which I can implement to improve file restore.

Thanks in advance!!

Prabhash

[foggy]

Prabhash, please review the full list of ports required for Veeam B&R components.

That said, in case VM is not available on the network, FLR via VIX is performed, so in fact direct connection to it is not required. However, in case of restoring a lot of data, it might indeed be slower.

I'm not sure about your topology and Veeam B&R version you're using, however keep in mind that v9 introduces mount server component specifically to avoid data being transferred back and forth during FLR when backups are mounted on the backup server itself.

[prabhash.jena]

Hi,

I had gone through that list. I would like to confirm for a normal file-level restore to a Windows server dos the mount server uses TCP port 2500 to 5000 only? or do I need any other ports to be open as well?

Thanks
Prabhash

[foggy]

According to the corresponding section in the ports list, you need to open dynamic RPC port range (TCP 49152-65535) and also TCP/UDP 135, 137 to 139, 445 ports (which are currently not listed there, but should be added, since used to inject our components into guest OS).

[prabhash.jena]

Thank you for your time and inputs. Much appreciated

[evilaedmin]

According to the corresponding section in the ports list, you need to open dynamic RPC port range (TCP 49152-65535) and also TCP/UDP 135, 137 to 139, 445 ports (which are currently not listed there, but should be added, since used to inject our components into guest OS).

In 9.5 u3, is the Guest Interaction Proxy component not involved in FLR for Windows or Linux? Thus the source of the above ports is the Backup / Mount server?

[foggy]

Correct, here's the corrected port requirements.

[mcz]

Just did a FLR and realized that a it takes a lot of time until the restore starts (3 minutes). By doing a trace I've found out that the server tries to connect to the client via the following ports:

• 445

• 80

After the 3 minutes, it uses port 6160, that should be the persistent guest agent. Is there a way (registry key??) to force veeam using that agent connection first?

Thanks!

[mcz]

Alexander, may I please ask for an update in this case? Thanks!

[foggy]

Hi Michael, sorry for the delay. The persistent agent should be attempted first by default in case the 'Use persistent guest agent' option is enabled in application-aware processing settings in the job. However, v11a has a known issue that it still tries admin share first - this is already addressed in v12. Thanks!

[mcz]

Thanks Alexander, that's a perfect answer!

[JaySt]

Hi Michael, sorry for the delay. The persistent agent should be attempted first by default in case the 'Use persistent guest agent' option is enabled in application-aware processing settings in the job. However, v11a has a known issue that it still tries admin share first - this is already addressed in v12. Thanks!

ok this is good to know. but, i'd really like this to be fixed in v11a as it could take a while before some of my customers are deploying v12. would support be able to provide a (private) patch or something?

[foggy]

Please open a case to request a hotfix. They will be able to review the situation and advise whether the hotfix can be implemented.

[mcz]

Foggy, I'm running the latest v12 version and it seems that this issue wasn't fixed. Just did a simple FLR of a very small file and it took more than 400 seconds (!!) to establish the restore session. In the trace I saw several SMB and RPC calls and it isn't communicating with the persistent veeam agent at first.

Expected or should it have been fixed? Thanks!

[mcz]

Any updates on that?

[JaySt]

I’m Starting to explore things arround this topic as well. Looking forward to an update and predictable behavior.

[foggy]

Any updates on that?

Hi Michael, sorry for the delay, and thanks for reaching out via PM. We've briefly checked it internally and it looks like guest processing itself and FLR work in the correct order while credentials test and validation prior to FLR chooses the wrong sequence. Please open a case so our engineers could take a closer look at what is happening in your environment and escalate to R&D in case the behavior is indeed not expected for addressing it. Thanks!

[mcz]

created case #06289508

[mcz]

ok, now I understand what's going on here... My support-engineer has told me that it (FLR) couldn't install the persistent agent:

<98> Info [RemoteGuestInstaller] installing via admin share

Now the thing is that there is already an agent installed and that's why we have blocked the SMB/RPC-connections and only allowed the communication to the guest agent... Veeam then gives up after a long time and starts the restore-process.

So, ideally, veeam checks FIRST if the guest agent exists, then only tries to install. If it's already there (like in our case) it could then start the restore and it would be damn fast . Makes sense, uh? Thanks!

[foggy]

Hi Michael, yes, makes perfect sense and I already see the feature request for this submitted internally. Thanks!

[mcz]

Thanks foggy. This doesn't sound as it was addressed in the next patches. Am I right?