Question regarding a weird difference between two methods of file level restore.
Scenario A :
Restoring about 10'000 files, 100 GB, directly to a Windows Server using the "Restore - Overwrite" option
Total time taken = 3 hours
Scenario B :
Restoring about 10'000 files, 100 GB, to a Windows Server using the "Copy To" option to the local backup server first, then copying from the backup server to the original Windows Server using SMB
Total time taken = 30 minutes
Why this difference ?
Both servers are connected through 10 Gbps links that are far from saturated.
I am sorry for the confusion, there is no bottleneck statistics available for a restore session, that's why it's hard to guess what was the reason for such performance.
You can contact the support and share the logs, it can help to find a reason. Thanks!
Restore to original has more metadata operations and need to enter file recover mode to set original privileges and other stuff. Test it at same server if it is really the same. Disk speed and available RAM/CPU is as well a huge factor.
Also, the server where the backup is mounted during the actual restore plays a role here: with the Copy To option, the backup it is the server initiating the restore (console or backup server), not the repository/mount server like in case of restore to the original location.
Thanks for your different replies. As suggested by Dmitry, I have contacted the support and here is their answer that others may find useful :
Going back to the description of the process of the Restore - Overwrite, on the contrary to Copy to operation which was performed on the local server where you started it, the Overwrite implied transferring data to another VM over the network.
At the beginning of both operations Veeam mounts the disks for you to be able to browse through the files. Then, Copy to transfers files to this local server without sending them anywhere, which is quite fast.
Overwrite operation starts the agent in the target VM. When it restores a file in this VM, first it checks whether the original file exists in the location specified, sends a request to delete this file, waits for a reply it was done, restores a new file and then notifies that this file has been restored well. After that, the process is repeated for every file in the list and consumes time apart from that spent on restoring it.
I think for my case the key information here was the whole check/request/reply/restore needed for the Overwrite option of the 10'000 files. I think it explains why it took a while.