Comprehensive data protection for all workloads
Post Reply
renpen
Influencer
Posts: 21
Liked: never
Joined: May 21, 2009 7:55 am
Full Name: Rene Lahaye
Contact:

Failed Replication

Post by renpen »

Hi there,

We have a several environments where we replicate large VM's across slow WAN links using WAN accelerators. This works well except when there is a failed replication due to some issues such as a WAN outage. I understand that the next replication pass will try and rebuild / repair the replica and this process may take some time. In our case it simply takes FAR too long and we often have to physically transport the target host back onsite to the source host to redo the replication. The VM's are typically around 400GB on a 2MB or 4MB WAN link.

In version 4.0 this did not seem to be the problem. Is it worthwhile going back to ver 4.0 to avoid this issue.


Thanks
Gostev
Chief Product Officer
Posts: 31766
Liked: 7266 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Failed Replication

Post by Gostev »

Hi, definitely not worth going back - we have not changed a thing in replication engine in v5 except of adding full support for thin disks... instead, I would recommend using full ESX as a target (instead of ESXi). This will make rebuild performed locally on target ESX (and thus very fast), instead of over WAN as in case of ESXi. The improvement will thus be dramatic. Thanks!
renpen
Influencer
Posts: 21
Liked: never
Joined: May 21, 2009 7:55 am
Full Name: Rene Lahaye
Contact:

Re: Failed Replication

Post by renpen »

We are using ESX full and not ESXi and the rebuild takes ages. I even logged support calls a few times but the feedback from them is always check your WAN connection etc etc. I am quite sure that in ver 4.0 when there was a failed replication this did not seem to be the case.
The only issue we had in ver 4.0 was that when a replication job was retried about 20 times without success the record would be lost in the DB and a full replication would then be run.
Gostev
Chief Product Officer
Posts: 31766
Liked: 7266 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Failed Replication

Post by Gostev »

Actually, you can be using ESX full but still in agentless mode - in case B&R cannot leverage service console for some reason. This should be seen from the log files. I would recommend re-opening the support case, and having support review the rebuild procedure. I would assume, for this they should ask you to provide agent logs from target ESX server (this is the only place where you can see how the rebuild process goes). If the rebuild is working fine and fast according to the logs (as it really should with the service console agent), then the issue is indeed connected to your WAN link. By the way, you may want to give your support engineer link to this topic as a starting point. Thanks!
renpen
Influencer
Posts: 21
Liked: never
Joined: May 21, 2009 7:55 am
Full Name: Rene Lahaye
Contact:

Re: Failed Replication

Post by renpen »

which log file and what would I be looking for to check if it is agent based or agentless?
Gostev
Chief Product Officer
Posts: 31766
Liked: 7266 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Failed Replication

Post by Gostev »

It should certainly be reflected in the log file for the job, but I am not sure where to look. Please, work with our support directly on this.
Bunce
Veteran
Posts: 259
Liked: 8 times
Joined: Sep 18, 2009 9:56 am
Full Name: Andrew
Location: Adelaide, Australia
Contact:

Re: Failed Replication

Post by Bunce »

Some more info here also:
offsite replication
renpen
Influencer
Posts: 21
Liked: never
Joined: May 21, 2009 7:55 am
Full Name: Rene Lahaye
Contact:

Re: Failed Replication

Post by renpen »

This is the response from support -

One thing you can do is to have veeam on destination side and try it that way instead. Replica's run better with veeam on destination side, backups on source side. Please advise any questions

I already have the Veeam server on the destination side. Come on Veeam support - surely you can do better than that :x !!
Gostev
Chief Product Officer
Posts: 31766
Liked: 7266 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Failed Replication

Post by Gostev »

This is true for ESXi target. With full ESX on target, there is typically no point to have the Veeam server on the destination side, because there is an agent already (in target ESX service console). Moreover, if you put Veeam server in target site, you loose network traffic compression.
renpen
Influencer
Posts: 21
Liked: never
Joined: May 21, 2009 7:55 am
Full Name: Rene Lahaye
Contact:

Re: Failed Replication

Post by renpen »

Support are looking at this further and requested all log files.
So, best practise would be to have Veem server on source site? How is it best to have the Veeam db available should the source site go down or not be available. You need the Veeam server available at the destination site to go back to previous replica's and failover.
Gostev
Chief Product Officer
Posts: 31766
Liked: 7266 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Failed Replication

Post by Gostev »

renpen wrote:So, best practise would be to have Veem server on source site?
Short answer, no. First, again - it depends on what is your target. Second, there are pros and cons in either approach. There is a detailed discussion about this around, search the forum for it if you are interested to learn more.
renpen wrote:How is it best to have the Veeam db available should the source site go down or not be available. You need the Veeam server available at the destination site to go back to previous replica's and failover.
There are ways to achieve that with Veeam DB in source site. There is also detailed discussion answering this question as well.

Trust me, most questions you may have about the product have been already asked and answered here on this forum before in the past years, so it is always a good idea to use search before asking :D
Post Reply

Who is online

Users browsing this forum: Google [Bot] and 44 guests