Changed Block Tracking : Backup and Replication of same VM

[tomas.olsen]

Hello everyone!

I have a question about using Veeam Replication.

I have set up replication from one Fiberchannel SAN to another for a customer. but it seems that the replication uses the virtual management switch. So the throughput is somewhat bad. I know that traffic sendt over the management switch of vmware have low priority and that is probably why I'm experiencing the bad performance.

Is there any best practice for using replication with a dedicated physical nic/virtual switch perhaps??

I cannot use Vmware CBT with replication since I'm already using Vmware CBT with Veeam backup.

this customer wants to have 28 restorepoints of all virtual servers to a Datadomain box, and a full replicated environment with just one restorepoint, from each day to a secondary fiberchannel SAN.

the througput I see with replication is 3 to 12 mbyte pr second, where most of the vm's is between 3 - 6 mbyte pr second.
when replicating 3 - 4 TB each day, this really takes some time.

I was somewhat surprised that replication traffic went through the management switch. I was convinced that when replicating between two fiber channel SAN, the traffic was kept only on the fiberchannel.

Oh, by the way, the veeam backup and replication server is virtual. I have only one Backup and Replication server for now, and it has four virtual cpu's and 4 gig memory and one virtual nic. The Vsphere environment consists of three ESXi 4.1 servers.

Best regards,
Tomas

[Gostev]

You can read source data directly from SAN, but writing to target is always done over network (typically, over WAN).

I cannot use Vmware CBT with replication since I'm already using Vmware CBT with Veeam backup.

Huh? Why you cannot use it for replication then?

[tomas.olsen]

So how can I redirect writing from the management network switch to a dedicated switch?

And about CBT:
I have been in contact with both veeam and vmware about CBT. And Veeam says it might work using both CBT with backup and replication of the same VM's. Vmware says that the CBT file in the virtual machine folder doesn't keep track of who accesses the CBT file, or uses timestamps.

If I run my backup job at 6pm, and my replication job at 01:00 am, both using CBT, I am afraid that the replication only copies changes since the backup job that used CBT at 6pm. And that the backup job the next day, only copies changes since the last replication job that also used CBT. This way, neither of the jobs are consistent.

if the CBT file records timestamps of when each block is changed, all kind of backup software should be able to check the timestamps and make up its own mind about which blocks have been changed since the last time it ran. Even if one or several other backup softwares have ran in the meantime using CBT.

[Gostev]

This is impossible. With the current version, writes have to go through the management network.

As far as your CBT concern, it is actually covered in the sticky FAQ topic.

If I run my backup job at 6pm, and my replication job at 01:00 am, both using CBT, I am afraid that the replication only copies changes since the backup job that used CBT at 6pm. And that the backup job the next day, only copies changes since the last replication job that also used CBT.

That is not correct. Backup job the next day will copy changes since its own previous run at 6pm, no matter how many CBT jobs processed this VM afterwards. CBT does not use timestamps to achieve this (that would be too unreliable and inefficient), but rather sequence numbers (aka ChangeID) that changed blocks are marked with by the hypervisor. Every job memorizes current ChangeID when taking snapshot, and during the next run, it only processes block with larger ChangeID than the one stored by previous job run. Obviously, the amount of jobs doing this on the same VM does not matter or affect anything.

[tsightler]

Right, this is covered in the FAQ (although Anton might consider adding his simple explanation above to the FAQ as it helps to understand the technology, and also fix the spelling of "brake" while he's in there )

>>> READ THIS FIRST : [FAQ] FREQUENTLY ASKED QUESTIONS <<<

[tomas.olsen]

Great, thanks for the excellent explanation Anton. This really helps understading how actually CBT works!!

So, to the final question.

If I setup a replication job each night of all the customers VM's to a secondary SAN. (about 50 vm's).
Does using CBT help when I choose to just have one restorepoint?
Does Veeam delete the first replica before or after the next replica is in place?
I mean, if Veeam deletes the firs replica before the next replication of the vm starts, I wouldn't think using CBT would help since Veeam must do a full replication anyway.

[Gostev]

Yes, CBT does help as our replication is forever-incremental.
Older restore points are deleted after successful replication cycle

[codot]

[merged into existing discussion]

Hi everyone,

I've got a tough one, technically speaking, for you:

Let's say we've got a VM to backup locally and replicate on another site. Both jobs have CBT enabled.

First backup job : CBT is enabled, full backup is done.
Second backup job : -ctk.vmdk file consulted and modified blocks are transfered (consider a forever incremental job).
First replication job : full replication is operated on the distant site.
Second replication job : -ctk.vmdk file consulted and modified blocks are transfered.

My problem is, once the initial full of each backup and replication job is initiated, how does the CBT is operated?

I mean, if there are multiple jobs done like backup-replication-backup-replication-etc... how does VEEAM knows that the changed blocks pointed in the -ctk.vmdk file are from a previous backup job and not from a previous replication job or the opposite?

Know what I mean? Is there some kind of index and history in the CBT file that VEEAM refers to? Let me know if my saying is unclear...

Thanks pal.

Clement.