Why Full VM restore job do not resume after short network connection drops?

[MAA]

Hello,
Why Full VM restore job do not resume after short network connection drops?
Why restore process do not starts from the point when the connection was lost?
I try to restore big VM (10 Terabytes) over 1Gb WAN for five days already, but no success - after short disconnections all have to start all over again.

[anthonyspiteri79]

Hey there ....

So if we look at the transfer speed of 10TB over a 1Gb WAN link without contention, you should be looking at about 20 hours. If we use 800Mbps to account for overheads it should take about 26 hours...that is without other factors such as disk read/write etc. I would say that as a first step you need to see why that transfer is being blown out to 5 days and what is causing the transfer to drop.

That doesn't change the fact that we do not have a resume function, however it still comes down to the unreliability of that link. One alternative would be to restore to local hard disk and ship that out.

[Andreas Neufert]

If I remember correctly our network timeout is arround 30 seconds. At least multiple seconds I belive, so enough time to cover all the typical network things. I rememer where we did our Backup Jobs from one end of the world to another end of the world reliable without our now integrated WAN accelerators and backup copy jobs. So the worldwide internet was stable enough accross the world to perform our backups. As Anthony said, please check your network and the environment as the transport should run faster by the given details above. As well all the usual network things should not affect usm so the question is what happens at the network "disconnection"?

[Gostev]

Yes, our data movers actually do keep "fighting" for quite some time in the hope that the network connection will restore, before giving up.

What transport mode are you using for restore, I hope its hot add? You need a virtual backup proxy on the cluster or host you're restoring to enable hot add. Otherwise, the restore will use NBD, which is extremely slow on 1 Gb, and is less reliable over WAN.

[Andreas Neufert]

You can maybe create a backup copy from it locally and restore from there. This would eliminate potential issues with VMware connections that we do not control (Anton mentioned NBD mode).

[MAA]

>>I would say that as a first step you need to see why that transfer is being blown out to 5 days
I already wrote - this is because when the connection is broken, the restory job starts from zero, instead of starting from the point where the connection drop occurred.
Veeam show errors like this:
"Restore job failed Error: ChannelError: ConnectionReset" or "Restore job failed Error: ChannelError: TimedOut"

>>and what is causing the transfer to drop.
Probably some problems on the ISP.