Restore VM from Azure Blob storage

[mogan2055847]

Hey Guys,

We are running VBR version.11.0.4.305. We have two internet links (Production internet WAN link and Backup internet WAN link), both with 200MB upload/download speed.
We have configured SOBR + Capacity tier to copy backup to Azure Blob storage, VBR server internet traffic route via the Backup WAN link, which configured by our network\firewall team.

Now, we are testing restore from Azure Blob in the event of disaster happen. Hope can obtain some guidance on below:

1. When performing VM restore from the Azure Blob storage back to on-premise Hypervisor, how to ensure the return traffic to VBR route via the Backup WAN link, and not the production WAN link?
2. Is there anyway to improve the recovery speed? Currently we are getting 20 Mb/s in average, is this normal? A test VM with size of 250GB took 5 hours plus to complete, that doesn't met our RTO if disaster really happen.


Thanks in advance.

[HannesK]

Hello,

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

Best regards,
Hannes

[GaryP]

If you need a better RTO then you need to look at replication, not backup. Veeam will replicate to a Cloud Connect provider, so maybe look there.

[datadrop]

Hi,

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.

Best regards,

Ulrich

[ITP-Stan]

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.

[HannesK]

a bit off-topic: latency has some impact, but there are many parallel threads...

doing the math, the speed looks okay to me.