Comprehensive data protection for all workloads
Post Reply
Chihiro
Influencer
Posts: 13
Liked: never
Joined: Aug 02, 2009 3:12 pm
Contact:

Incremental Taking Same Time as Full

Post by 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
VP, Product Management
Posts: 5689
Liked: 2509 times
Joined: Jun 05, 2009 12:57 pm
Full Name: Tom Sightler
Contact:

Re: Incremental Taking Same Time as Full

Post by 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).

Post Reply

Who is online

Users browsing this forum: No registered users and 45 guests