Slow replication after ESX reboot

[renpen]

I have successfuly run 2 VM replications jobs across quite a slow WAN link for the past few weeks. Last week the source ESX servers rebooted and since then the subsequent incremental replications take forever. In fact I have not been able to complete a replication pass since then as it simply takes too long.
My question is if the ESX servers are rebooted does Veeam need to rescan the entire VM's again?
I have Expand accelerators between the source and target ESX sites and watching the amount of traffice being generated it certainly seems this way.
Looking at the size of the VRB file while this is hapening it is only growing very slowly.

[Vitaliy S.]

Hello Rene,

No Veeam doesn't need to rescan the entire VM after host reboot. Could you please clarify what replication mode are you currently using, as well as your setup (ESX host versions)? It would be also great to see a job log for your replicas, because there might be some additional information on your speed issue.

Thank you!

[renpen]

ESX4.0 Update 1 and using vstorage API (network) and using CBT.
I have been running the replication on a 400GB VM across a gigabit LAN for 6 hours now and the job is only at 38%

[Vitaliy S.]

Rene,

I'm a little bit confused with your last post, are you replication across the slow WAN link or a gigabit LAN? Could you please clarify? What was your initial speed on the first run? Do you see the same low replication job speeds for all VMs on the host you've just rebooted?
Assuming you see the VRB file is growing, it will be interesting to see what is causing such a delay for you, have you had a chance to contact our support directly providing all the job logs?

Thank you!

[renpen]

Hi moderators.

The issue I had after the source ESX servers had rebooted has been identified as a bug in 4.1. The case ID is 525717.
Basically what is happening is that I have 2 replication jobs that loop each other so that when one job ends the other one starts.

See response from support below:


Unfortunately, we found a bug in our product. After the mentioned source ESX host outage, our product has taken near 15 retry attempts before ESX host became up and running. Almost all of them found previous record in the DB, and only latest attempts stopped finding records of previous runs. I have discussed possibilities of fixing of that issue with our development team and they told me it would be fixed in our future releases.
If you send us the screen-shot of your destination folder (full view with dates of file modification) we could try to modify your DB, and it will find a record about previous run, and "incremental" run would be started instead of "full" one. We could not guaranty the result of that modification would be success, but we still could try.
As a workaround I guess it could help to avoid running jobs while source ESX host is down. Because in your particular case, if the ESX host would be powered on in a short time, while Veeam still had information about about previous runs in it's DB, Veeam would run the job using "incremental" mode.