Very slow restoration process from second-stage BKP

[TheBluesFAN]

Hi.

My problem is that when I want to restore a VM, or anything else from the second stage of BKP it takes a very long time.

Comparison of restore in my configuration:
1. from Veeam server (it is also the first tier of BKP)
- BKP --> about 5 Gbps
- Restore --> about 2 Gbps
2. from Hardened Repository
- BKP --> about 2 Gbps
- Restoration --> about 200 Mbps

I believe it is not the fault of the network connections as BKP speeds are high. The Linux Hardened Repository configuration is not standard, but it keeps its general assumptions.

During restoration, CPU and RAM usage of all 3 servers is at a minimal level, rather unaffected by the task.

I monitor everything with Zabbix and noticed that during restore the following parameters are strange in my opinion:
- Disk Latency Read on LUN --> 8000 ms on average.
- IOPS Read on LUN --> average 40
- Network Latency TX on LUN --> average 40000 ms (with BKP about 15 ms and less)

Where could the problem be? What is causing the restore to be so slow?

I also attach a graphical preview of my configuration.

[PetrM]

Hello and Welcome to Veeam R&D Forums!

The first step is to identify the "bottleneck" - the slowest data processing stage. The most reliable way to do this is to open a support case and ask our engineers to review the debug logs. My assumption is that the data read from the LUN is slow, and regardless of network speed, the data processing conveyor (restore job in our case) cannot operate faster than its slowest stage. It might be worth testing the data read speed on a Linux server from Synology using another tool, such as FIO. However, this is just an assumption, I prefer to leave the troubleshooting to our support team.

Also, please share the support case ID with us so that we can keep track of it.

Thanks!

[TheBluesFAN]

Thank You for your advice.

Case number is 07581301