Veeam FLR restore takes way too long

[RubinCompServ]

We’re doing a FLR of a 75GB folder that contains 104k files. In this case, the VBR is functioning as the “all-in-one” location – it is the mount point for the backup and the files are getting restored (via “Copy To...”) to a drive on the same server. When I restore the files using the Veeam backup browser, it takes hours to restore (it’s been running for an hour now and has only restored 20k files). However, when I browsed to the Windows mount point (C:\VeeamFLR) in Windows Explorer and copied the files directly from there, I got all of the files in just under an hour. All other variables are identical as the (current) restore via the Veeam backup browser is the same session as when I copied the files via Windows.

[RubinCompServ]

In case my post wasn't completely clear, here's a timeline:
12:15pm - started FLR wizard from Veeam and selected restore point and mount server
12:25pm - within Windows, browsed to C:\VeeamFLR, and drilled down to the folder I wanted to restore. Copied the folder to a local drive
1:22pm - Windows file copy completes (104k files)
1:25pm - deleted restored folder
1:26pm - used (already running) Veeam backup browser to restore the same folder to the same location, using the "Copy To..." button.
2:37pm (right now) - only 22k files have been copied so far to the destination.

[Gostev]

You're comparing apples to oranges here as for example unlike restoring through Veeam Backup Browser, simply copying files from a folder does not create audit trace for restored files.

[RubinCompServ]

That as may be, but does that audit trace justify a literal 400% increase in time? Copy files manually took an hour, using the Veeam browser took 5 hours.

[Gostev]

I never said this is the only difference, just that you can't compare the two methods directly as they are very different from the backend perspective.

[RubinCompServ]

Which brings me back to my original point: the Veeam browser takes way too long to restore files. It's primary job is to write data. That's its reason for existence, its purpose in life. So what is it doing for the 80% of the time that it's not actually writing data?

I'm not asking this for a sake of starting trouble; I have some seriously upset customer who want to know why our highly-touted Veeam solution is taking so long to restore their data, and I don't have anything to tell them.

[Gostev]

Your seriously upset customer should contact our Customer Support and they will see if anything can be done to improve the situation in their environment.

[RubinCompServ]

Case #07487999

[Samba222]

interesting... I have already noticed that, also for a big amount of data its not usable. I am looking forward to the outcome.

[princeinzion]

Apologies in advance, this is me just being funny: Its probably making sandwiches and pizzas or applying the 80/20 percent rule.

Which brings me back to my original point: the Veeam browser takes way too long to restore files. It's primary job is to write data. That's its reason for existence, its purpose in life. So what is it doing for the 80% of the time that it's not actually writing data?

[YouGotServered]

I'd also be interested to know the discrepancy for the time it takes to restore. I have noticed this myself in the past (although I don't have metrics for it, but Veeam FLR always did seem much slower than a file explorer copy when all other variables stayed the same). I'd like to know what is going on behind the scenes here, too.

[RubinCompServ]

Apologies in advance, this is me just being funny: Its probably making sandwiches and pizzas or applying the 80/20 percent rule.

TBH, if it was making pizzas, the customer would probably be happy with that...