thanks guys,
Just an update on the file level recovery issues.
There were two issues.
1. On the repository configuration, on the Linux mount server, I changed this to be the Appliance device itself. Prior to this I was using one of the deployed JeOS proxies, but I'm assuming the JeOS deployed proxy didn't have the data mover component (or some other component required by the file recovery process) on it so it wouldn't get to the screen that shows the tree view of the backed up OS file system. I didn't need to use a Windows mount server in my tests (which is great!).
2. For the file level recovery to work on a windows 2025 test VM, I had to enable the firewall inbound rule "File and Printer Sharing (SMB-in)", otherwise the connection hangs with "Checking credentials" and then eventually after about 10 minutes or so fails with "an unexpected server error occurred". It would be more useful if that timeout could be significantly reduced to say 10 seconds.
The default windows firewall configuration disables inbound SMB traffic, it might be worth highlighting that it may need to be temporarily enabled in the target machine for an FLR to succeed (this issue existed prior to v13 though).
In our case to lock inbound SMB traffic to a specific set of IPs (corresponding to where the traffic might originate) we run the following PowerShell command on the machine we need to restore individual files to allow SMB inbound traffic but only from our backup infrastructure (e.g. our 4xproxies and Veeam appliance);We don't often use the file level recovery, but the functionality of this in v13 is quick and efficient once its configured correctly.
So on my side everything is looking great, I'm going to tear everything down again, and recreate the appliance and proxies (on JeOS) and dial it in Entra and then recreate the V12 jobs in V13, then run some larger scale tests and compare the stats to V12.
cheers
Ashley
Just an update on the file level recovery issues.
There were two issues.
1. On the repository configuration, on the Linux mount server, I changed this to be the Appliance device itself. Prior to this I was using one of the deployed JeOS proxies, but I'm assuming the JeOS deployed proxy didn't have the data mover component (or some other component required by the file recovery process) on it so it wouldn't get to the screen that shows the tree view of the backed up OS file system. I didn't need to use a Windows mount server in my tests (which is great!).
2. For the file level recovery to work on a windows 2025 test VM, I had to enable the firewall inbound rule "File and Printer Sharing (SMB-in)", otherwise the connection hangs with "Checking credentials" and then eventually after about 10 minutes or so fails with "an unexpected server error occurred". It would be more useful if that timeout could be significantly reduced to say 10 seconds.
The default windows firewall configuration disables inbound SMB traffic, it might be worth highlighting that it may need to be temporarily enabled in the target machine for an FLR to succeed (this issue existed prior to v13 though).
In our case to lock inbound SMB traffic to a specific set of IPs (corresponding to where the traffic might originate) we run the following PowerShell command on the machine we need to restore individual files to allow SMB inbound traffic but only from our backup infrastructure (e.g. our 4xproxies and Veeam appliance);
Code:
New-NetFirewallRule -DisplayName "Allow Veeam FLR inbound SMB" -Direction Inbound -Action Allow -protocol TCP -localport 445 -RemoteAddress @('1.2.3.4','1.2.3.5','1.2.3.6','1.2.3.7','1.2.3.8')So on my side everything is looking great, I'm going to tear everything down again, and recreate the appliance and proxies (on JeOS) and dial it in Entra and then recreate the V12 jobs in V13, then run some larger scale tests and compare the stats to V12.
cheers
Ashley
Statistics: Posted by ashleyw — Sep 16, 2025 1:00 am
