VDR cpu usage while processing empty blocks

[toha]

Why is "datarecovery" process using 100% CPU while processing empty parts of VMDK? Is dedup algorithm so complex (read unefficient) that it needs 100% CPU for processing zeros?

Please educate me

[RParker]

backup starts, until the backup ENDS there is STILL processing going on, regardless if there is dead spots or zero bits.

Does the backup complete? Is everything ok after that?

I wouldn't worry about HOW VDR works, as long as it works.

[toha]

Sometimes initial backups complete, sometime not.

For example I wiped my backup storage today in my lab system and created new backup schedule. VDR started to backup guests, three was completed without problems but three did not ever complete, and I did wait long time. All backups were started at same time and VMs are very close to eachother in size vise.

I was able to stop hanging backup processes and VDR started backup for two missed VMs again, lets see how it goes this time.

Update: Now some of backups completed. But still one of three backups were significantly slower than others, it didn't even speed up after other backups complete.

I see from logs that normal backup speed is 1 gigabyte/minute, these forever running backups report speed of ~50 megabytes/minute. Problem is CPU load, but why slow backups won't gain speed after resources are freed from completed backups?

[admin · Accepted solution]

For HW7 VMs we do not read the zero blocks from the disk but we do chunk through the zero blocks in the dedupe store. If the disk has a large number of zero blocks then for the HW7 VMs the zero block chunking will be done only during the first backup - since we leverage change block tracking after the 1st backup. For HW4 VM this will happen at the time of every backup since there is no change block tracking support.

[toha]

Thanks, this clears things up.