question about multiple servers and bandwidth sharing

[robg]

Hello, I have two sites A and B, I plan to deploy separate copies of veeam at each in order to pull replication VMs from the other, that way if one goes under I can initiate a proper failover from the working side.

I will run the enterprise manager, however both sides will have separate throttling configs, and I assume they are not aware of each other. In other words if I have to limit to 5 mb/s and the replication for both occurs simultaneously, will the proxies be smart enough to split them to 2.5 or will it end up using 10?

Thanks in advance

[Gostev]

Hi, Rob. No, traffic throttling rules only apply to activities initiated within the given B&R server install. Thanks!

[robg]

I see. Could there be any risk of interference or corruption? Say one server in site A is replicating a VM from site B, and the second veeam server instance at site B is backing the same VM up, separately.

I'm sure this can be avoided with the same server backing up and replicating, however I have found that Guest OS restore operates much slower when run across a WAN. Thanks for your help

[Gostev]

No risk of problems, collisions, corruptions or any other interference that I can think of.

[nathanael.duke]

A notable exception that comes to mind is Changed Block Tracking, or CBT, which will update for each job that directly reads the VM source data, causing a mismatch between what is reported as having changed and what has actually changed since the last time a given backup or replication job last ran.

The consequence is only that a full end-to-end read of the VM's disk files would be required for each job running against that single VM, but for extremely large VMs this may not be an acceptable consequence.

[chrisdearden]

A notable exception that comes to mind is Changed Block Tracking, or CBT, which will update for each job that directly reads the VM source data, causing a mismatch between what is reported as having changed and what has actually changed since the last time a given backup or replication job last ran.

The consequence is only that a full end-to-end read of the VM's disk files would be required for each job running against that single VM, but for extremely large VMs this may not be an acceptable consequence.

Sorry but thats not the case or the thousands of customers we have that back a Vm up in more than one job (or backup and replicate the same VM ) would have performance issues. Think of CBT as a journal -as far as I'm aware each process that accesses that journal has its own set of pointers within that journal and thus will be independent.

[nathanael.duke]

Thanks for the reply, Chris.

I'm a bit curious about this, as the VMware KB at http://kb.vmware.com/selfservice/micros ... Id=1020128 describes CBT functionality rather ambiguously as "CBT identifies the disk sectors altered between two change set IDs."

I am very interested in getting a better grasp on the mechanisms that underpin CBT. As more of a journal, it should be able to give a full accounting of changed blocks without regard to whether or not the backup solution in question was the last to actually take a backup of that VM.

Can you think of any reason why CBT might fail in a situation where multiple Veeam servers are accessing the same VM? I have seen it before, but now that you're telling me that the CTK is a running journal, I think I may have misunderstood the cause of the failures.

I'm going to take some time to raw hex diff a few versions of my CTK files in between backups so I can see for myself what's going on.

Thanks!

[chrisdearden]

I've not come across it myself, but as I understood it it shouldn't matter if the changed set ID's are from the same veeam server or not ? I dont think individual ctk files are generated for each process?


I should have known to ask Gostev first

https://communities.vmware.com/message/2021423

[Vitaliy S.]

A notable exception that comes to mind is Changed Block Tracking, or CBT, which will update for each job that directly reads the VM source data, causing a mismatch between what is reported as having changed and what has actually changed since the last time a given backup or replication job last ran.

Can you think of any reason why CBT might fail in a situation where multiple Veeam servers are accessing the same VM? I have seen it before, but now that you're telling me that the CTK is a running journal, I think I may have misunderstood the cause of the failures.

Definitely there cannot be any issues with CBT being leveraged by multiple backup/replication jobs.

[robg]

Definitely there cannot be any issues with CBT being leveraged by multiple backup/replication jobs.

Multiple Veeam servers manipulating the same VM, not multiple jobs on one server.

[Vitaliy S.]

Even this, you can backup the same VM with any number of backup servers and use VMware CBT. Each job will be storing its own CBT info.

[robg]

Even this, you can backup the same VM with any number of backup servers and use VMware CBT. Each job will be storing its own CBT info.

I started to get CBT errors on both jobs, on both servers shortly after attempting this. I opened a case about it and was told that it cannot work.

I'm kind of amused that you guys don't seem to agree on it.

[Vitaliy S.]

CBT errors could have been caused by something else. Can you please post your case ID so that we could track it as well?

[robg]

CBT errors could have been caused by something else. Can you please post your case ID so that we could track it as well?

00635145

Due to a scheduling error/mistake a backup and replication job from 2 separate veeam servers tried to run at the same time, that's about when this started.

[Vitaliy S.]

If both jobs were using application-aware image processing (VSS), then I can see why they could have issues. Trying to freeze the Guest OS at the same time can cause unwanted affects, I have pinged your engineer on more info regarding debug logs analyses.

[robg]

If both jobs were using application-aware image processing (VSS), then I can see why they could have issues. Trying to freeze the Guest OS at the same time can cause unwanted affects, I have pinged your engineer on more info regarding debug logs analyses.

That's probably it then, it's not a big concern for me at this point because I have reset CBT and eliminated one of the veeam servers..

[robg]

I would like to add to this thread that it would be nice if multiple instances of veeam were aware of each other, maybe stop the operation and throw an error like "VM is currently locked" - the way it is now when the same server attempts to backup and replicate at the same time.

As referenced in another recent thread, it can get very cumbersome to manage multiple copies of veeam, especially in a situation where replication is happening in two directions, not just to a DR site.

[veremin]

You can deploy Enterprise Manager, add both servers to it, and have required visibility across backup servers - what jobs are currently running, etc. Thanks.

[robg]

I don't just want visibility, I mean true centralized management.. Consider it a feature request. One master copy of veeam and "slave" consoles at all the remotes where failovers can be initiated.

[veremin]

Visibility through Enterprise Manager would at least give you some clues on what is happening right now on both backup servers; what server runs what and so on. As to centralized management feature request, your voice is counted. Thanks.