1. that's something to ask the network team. Routing is done at network level (not on application level). If the upload works via the backup WAN, then I would expect that download would also go that way. At least most network admins try to avoid asynchronous routing because it can cause ugly issues
2. Just to clarify... you have a 200Mbit/s link (25MByte/s) and you get 20MByte/s download speed? If that's the case (and not 1.6Gbit/s with 20Mbit/s speed), then it sounds like the link is doing around 80% of its capacity. I don't know how much overbooked that link is by the internet provider, but that sounds expected to me. From a Veeam side, you could try optimizing restore by using change block tracking restore / quick rollback.
that doesn't met our RTO if disaster really happen.
then probably more bandwidth is needed - Veeam (like anyone else) has to respect the laws of physics
bandwidth is not everything, you also have to take network latency into account. As far as I know, as long as TCP waits for acknowledgements, no data is transmitted. Thus high latencies gnaw at the download bandwidth. This is the reason why WAN optimizers like Riverbed exist. In other words, the speed of light can be too slow.
TCP does not wait for 1 packet to be acknowledged before sending other packets. There is a buffer window of packets.
TCP will however resend the packet if the acknowledgment does not arrive within a set time window.
