Backup without CBT faster than with CBT

[lorenzo]

During this period with CBT bug in VMware 6, I disabled CBT features in some of our customer backup job. In some case I was worried not to complete the backup job over the night period, but it result that not using CBT was faster (5% to 10%) than using CBT. Job statistics clearly say that data read is almost doubled not using cbt than using cbt, data transferred after dedupe and compression is almost the same and the duration of the job slightly decreased. How is that possible?
Thanks in advance

[PTide]

Hi,

and the duration of the job slightly decreased

Could you give us exact numbers (backup durations) please? Because if it was something like 20m00s and 22m00s (10%) then I'd say that the difference is not significant and can be explained by difference in loads on your production storage, backup storage, etc. So please share your numbers and job statistics.

Thank you.

[Vitaliy S.]

Also check if you've made any changes to processing mode, this can affect job duration.

[lorenzo]

First of all I disabled CBT in the "Advanced settings" of the backup jobs, then I ran an active full backup of the jobs.
As you ask for numbers, this is an example:

Job with CBT enabled (this is not an active full but a reverse incremental one)
Start time7:30:14 PM - Total size5.3 TB - Backup size2.6 TB
End time6:44:40 AM (+1) - Data read2.3 TB - Dedupe1.4x
Duration11:14:25 - Transferred166.9 GB - Compression1.6x

Job without CBT (this is not the first active full but it is a reverse incremental job of some days later)
Start time7:30:17 PM - Total size5.3 TB - Backup size2.5 TB
End time5:42:57 AM (+1) - Data read5.2 TB - Dedupe1.3x
Duration10:12:40 - Transferred162.1 GB - Compression1.6x

Between downgrading VMware (from 6 to 5.5) and disabling CBT I chose the second solution. I applied this solution to a few clients' clusters and I was expecting really long backup time but this is not what happend. Now I 'm trying to understand the reason of the results.

[alanbolte]

Do you have a target-side bottleneck? If reading data ('source') isn't a significant bottleneck, then the amount of data read won't have a significant impact on your backup duration.

[lorenzo]

With CBT bottleneck was:
Load: Source 32% > Proxy 15% > Network 61% > Target 46%

Without CBT bottleneck is:
Load: Source 57% > Proxy 35% > Network 41% > Target 23%

[Vitaliy S.]

Additionally, I would suggest to check what operation took most of the time for each job by looking through the job session details.