Incremental Taking Same Time as Full

[Chihiro]

Is it just me, or do incremental backups take the same amount of time as fulls? The strange thing is, the data delta size (reverse-incremented .vrb file) is, as-expected, always much less than the original full backup.

For example, immediately after running a full backup that took one hour to complete and that generated a 10G .vbk file, if I run the same job again, the job runs for another hour and but only generates a 100M .vbr file. Within the Veeam console, the subsequent/incremental backup is running for an hour, but only generates small .vbr files. This is all recorded in the log/report.

So is it actually using all this time to calculate differences on the guest VM, or is this time being used to merge/synthesize on the Veeam console (meaning, no load on the ESX server), or is it something else?

[tsightler]

Because VMware ESX prior to 4.x did not provide tracking of block changes the only way for Veeam to find the changes is to read the entire VMDK again. This basically means that incrementals require the same amount of disk IO as full backups and thus will be limited to the speed that the VMDK file can be read from disk.

vSphere 4.x has support for block change tracking and Veeam has previously stated that Veeam Backup 4 will include support for this feature so once this is available incremental backups should be much faster since it will literally only need to read the actual changed blocks (ESX does the effort of tracking changed blocks on the fly).