Backup and Replication performance using VCB

[matthadley]

Just to confirm -- if a large file is created and deleted between backup or replication job runs, the next job will assume that all of the changed blocks need to be copied as the VCB is read sequentially as a log, correct? This comes into question, in our environment, when a SQL backup is first written locally, moved off the guest, and then deleted between replications.

I believe the answer to the question is, "yes." And, if so, we should be able to direct the backup to a separate VMDK and exclude that from the replication process.

[Gostev]

With VCB, all source VM blocks needs to be read each time incremental backup runs to determine the changed blocks, as VCB does not support changed block tracking.

For fast and efficient incremental backups, you need to upgrade to vSphere 4 or 5, where we can leverage changed block tracking, so that only actually changed blocks are read and then transferred.

[matthadley]

Whoops, my mistake. I meant to infer changed block tracking. Between replications, if a large number of blocks are changed as a result of a file created and then deleted, I presume that a replication based upon such will see all the blocks as changed and replicate them. Correct?

[Gostev]

Yes and no. Deleting a file in most file systems does not update actual block backing the file, CBT will not see any disk changes as a result of a simple file deletion. However, if you create and then delete the file - the "create" part will of course change the contents for many disk blocks, so CBT will see those blocks as changed, and will pick them up. Thanks.