Incremental backup transferring more data than full backup?

[Carko]

Hi,

I currently have a very simple test setup in which I have a VM host and another host which contains both the proxy and repository.

Apparently CBT got "stuck" on one of my VMs so I had to reset it (per the KB article) and restarted the incremental job. Now I understand that the first time after is it restarted the CBT tracking is not yet used; instead BR uses its own algorithm to detect changed blocks and it appears that in this case it transfers _everything_ from the VM host, which does make sense in a way.

However, the full backup with dedup and compression enabled seems much more efficient.

For example, if I have two VMs (100GB and 200GB) in one job:
- full backup processes less than 30GB
- incremental backup without CBT (or with CBT re-enabled for the first time) processes all 300GB(?)

Is this how it works or am I misunderstanding something? Wouldn't it be more efficient if BR created a full backup and then did its own CBT to create incremental backup?

[Vitaliy S.]

Hello Carko,

Processed data is not the same as transferred data. When VMware CBT cannot be used, we are using our proprietary changed block tracking engine, that basically scans source VM image, calculates hashes for all blocks, and then verifies what blocks have been changed on your VM compared to the VM image stored in the backup file. This process requires processing of the entire VM, but only changed blocks are transferred to the target repository.

Could you please tell me what values do you have for read and transferred counters?

Thank you!