dedup ratios on windows and linux VMs

[dmitri-va]

Hello,

we are testing Veeam backup v8 and are observing the following dedup ratios on weekly full backups for red hat enterprise linux and windows virtual servers:
-qty 5 windows VMs: ~2.1
-qty 5 RHEL VMs: ~5.1

I was hoping to see 5x ratio on average and am surprised by the lower then expected ratio on windows VMs. Do these look as expected?

[foggy]

Dmitri, dedupe ratio depends on the actual content inside the guest OS's of the backed up VMs, not just their OS type. The more similar VMs in terms of content are (created from a single template, running similar apps...), the higher dedupe rate is. Also, do both jobs have the same storage optimization setting (block size)? Smaller block leads to higher dedupe rate.

[dmitri-va]

appreciate the fast reply. I will be running multiple tests with different parameters to find a sweet spot between dedup and/or compression ratios, backup duration and the loads. The first run was using 'local target' storage optimization.
I will alos test VMware data protect on the same VM set to see if it's any different.

I need to be able to estimate the total storage capacity for backing up our environment. We are 50/50 mixed Windows 2008/2012 and RHEL shop and we are shooting for 30 day retention with daily incrementals and weekly full backups.
Unless someone has a better rule of thumb for dedup ratios for our scenario, I'm going with 1x for incrementals and 5x for full backups for now.

[dmitri-va]

ok, first mistery solved

linux backup job was showing 980GB total size, 253GB data read, 235GB data transferred and 190GB backup size, so 980/190 = 5.1

windows backup job was showing 901GB total size, 789GB data read, 424GB transferred and 421GB backup size, so 901/421 = 2.1, so worse ratio than linux due to less empty space

btw, is this industry standard to calculate dedup ratio using total size which may inlcude a lot of free space, vs actual data to backup / resulting backup size, which in the above case is ~1.1 for linux and ~1.8 for windows?

also, no difference between data read and data transferred for linux means dedup did not happen on the clients, right? (inline dedup is enabled). if so, any reason for it?

[foggy]

btw, is this industry standard to calculate dedup ratio using total size which may inlcude a lot of free space, vs actual data to backup / resulting backup size, which in the above case is ~1.1 for linux and ~1.8 for windows?

In fact, this is exactly what is reported as data reduction ratio in the job statistics (read divided by transferred).

also, no difference between data read and data transferred for linux means dedup did not happen on the clients, right? (inline dedup is enabled). if so, any reason for it?

Nothing to dedupe, probably (unique data).

Unless someone has a better rule of thumb for dedup ratios for our scenario, I'm going with 1x for incrementals and 5x for full backups for now.

We typically suggest at least 50% data reduction. But depending on data pattern it can be higher, of course.