Interpreting statistics about compression and deduplication

[m.novelli]

Hi friends, some questions about compression and deduplication statistics regarding a backup job with incremental mode and transformation of previous full backups chains into rollbacks:

- what means a deduplication ratio of 99% for incremental backups? It means really high dedupe or no dedupe?

- compression ratio for VRB files generated from transformation is 100%, that means no compression? On disk I can see that VRB files are near the double than VIB files

A side note: transformation of previous full backups chains into rollbacks for a 1TB VBK file took about 23 hours on this Veeam Backup Server (Dell R710 with 4 vCPU Intel E5620, VBK located on an iSCSI Dell MD3000i with SATA hard drives). For this customer is not a big issue, but I have other customer with bigger HW infrastructures where a so long transformation time will be unacceptable considering that in the meanwhile the Veeam Backup would process other jobs

Thanks for any explanation

Marco

[Gostev]

Hi Marco, please see here for the explanation.

Also, please note that transformation process can be fully offloaded to target when backing up to Linux target, thus it will not be affecting your backup server. If the customer is using version 5.0.1, we would be interested to take a look at transformation log to see what makes the transformation run so long. Thanks!

[m.novelli]

I've updated this customer to Veeam 5.0.1 yesterday, I'll wait the weekend to have a new transformation process and I'll send the logs to Veeam Support

Regarding VRB files generated from transformation process, is correct that are not compressed? This is a quite bit waste of disk space

Marco

[Gostev]

Everything is compressed if you have compression enabled (which is the default setting). That includes VRB, VBK and VIB. You may want to do active full backup on existing 5.0 job though, because 5.0 had a bug resulting in VBK growth during transform, and as you know VBK cannot shrink itself without full backup (can only reuse unused blocks).

[m.novelli]

Right, last weekend my VBK growth from 950 GB to 1200 GB during transformation and I was wondering why!

You are guru

Marco

[Gostev]

Nah, I just read release notes for 5.0.1

[ctchang]

Sorry to interrupt, but where can I see dedup/compression ratio in the backup result report?
I couldn't find it anywhere.

[Vitaliy S.]

Jack, just navigate to Backups, choose any backup job on the right pane and then click Properties, everything you need should be right there

[ctchang]

Jack, just navigate to Backups, choose any backup job on the right pane and then click Properties, everything you need should be right there

Thanks, but I was really asking where can I find the compression ratio in my backup result?
ie, after a job is completed, there is a reported compression ratio as described by the one who started this post.

[Vitaliy S.]

Oh... I see, but compression and deduplication ratios can only be observed in the backup properties and not in the sessions history, that is why you couldn't find it.

[Gostev]

Sorry to interrupt, but where can I see dedup/compression ratio in the backup result report?
I couldn't find it anywhere.

Actually, we have already discussed this with you just 1 month ago here.

[ctchang]

Actually, we have already discussed this with you just 1 month ago here.

wow...I almost forgot it after busy with our vmw project for the past months.
Your memory must be huge to fit in all the little details.
Thanks again.

[m.novelli]

Hi Marco, please see here for the explanation.

Also, please note that transformation process can be fully offloaded to target when backing up to Linux target, thus it will not be affecting your backup server. If the customer is using version 5.0.1, we would be interested to take a look at transformation log to see what makes the transformation run so long. Thanks!

After updating to Veeam 5.0.1 the transformation process took 32 hours for a 1,1 TB VBK file

I'll send the logs to support

Marco

[m.novelli]

I've opened the ticket ID#547864

Marco