Hi dasfliege,
Deduplication is done on the source side before transferring to the target datamover.
Processed may be throwing off your calculations a bit as Processed is related to the total size of all VM disks processed by the job, not the actual allocated/used space. I would focus on the read and transferred amounts, and keep in mind because the backup process works at the block level, even a small change in a block results in the entire block being marked as changed (i.e., if even a few bytes of a 1 MB block change, the entire block is returned by RCT as changed) So the total Process/Read/Transferred may be higher than actual changes on the guestOSes, but you still need to accommodate for the amount of changed data.
VeeamOne is really best best for this, but your strategy is sound and probably it will be accurate. Tracking the space savings in full from fast clone unfortunately is a challenge as there isn't a convenient way of knowing how much was fast clone'd versus written normally, so in addition to tracking what was processed during the backup jobs, tracking the growth rate of the actual space usage on the repository is best to include in your calculation as well.
Your understanding is correct. Read is the total amount returned from the Hypervisor when we query for changed data (or all data in the event of Active Full), and transferred is the amount sent from the source datamover to the target datamover. (i.e., from the proxy to the repository)I wrote a scripts which searches for the last successfull run of each backupjob and compares "Processed" with "Read" data and calculates the changerate. To my understanding, "Read" is the value that CBT (Or RCT in our hyper-v case) is reporting as changed data. "Transfered" is the amount ouf data that really is travelling through the network after it has been compressed by the source proxy. Is this correct? Where is per-job dedup happening in Veeam. Do i have to take this into consideration when reading the job session stats or is it happening afterwards?
Deduplication is done on the source side before transferring to the target datamover.
Processed may be throwing off your calculations a bit as Processed is related to the total size of all VM disks processed by the job, not the actual allocated/used space. I would focus on the read and transferred amounts, and keep in mind because the backup process works at the block level, even a small change in a block results in the entire block being marked as changed (i.e., if even a few bytes of a 1 MB block change, the entire block is returned by RCT as changed) So the total Process/Read/Transferred may be higher than actual changes on the guestOSes, but you still need to accommodate for the amount of changed data.
VeeamOne is really best best for this, but your strategy is sound and probably it will be accurate. Tracking the space savings in full from fast clone unfortunately is a challenge as there isn't a convenient way of knowing how much was fast clone'd versus written normally, so in addition to tracking what was processed during the backup jobs, tracking the growth rate of the actual space usage on the repository is best to include in your calculation as well.
Statistics: Posted by david.domask — May 27, 2025 8:17 am
/english-betterindia/media/post_attachments/uploads/2022/05/Sustainable-home-10-1651667432.jpg)
