Per-VM backup repository and dedup ratio for repository sizing

[balma01]

Using the Per-VM backup repository setting do not provide deduplication between VMs.
In this case, which dedup ratio (Data left after reduction) have we to insert in the repository sizing tool RESTORE POINT SIMULATOR?
You can find the tool at http://rps.dewin.me/

[foggy]

It is typically recommended to use the Conservative (50% reduction) setting provided the default Optimal compression level is utilized.

[balma01]

Hi foggy, thanks for your help. I understand It is typically recommended to use the Conservative (50% reduction) setting provided the default Optimal compression level but if I use a Per-VM backup repository I guess to insert a different reduction...

[Andreas Neufert]

No, it is the same.

Compression is applied inline during backup to each data block that we read. If you later pack this together in a big file or multiple small file do not change anything on the size side.

However that said, our Inline Deduplication ratio could be affected by it. For example you clone 10 VMs an backup those, then the dedup effect from a per VM chain is way less compared with a per job chain. Anyway the 50% data reduction is a very good conservative number together with 3-5% change rate. (3% for non Database systems, 20% for Database systems)

[foggy]

The thing is, it heavily depends on the data itself, compression might give more or less savings depending on the data pattern. So 50% is already a rough average not counting for that. Of course, per-VM chains do give you less reduction but 50% is still a rough average - Veeam B&R uses pretty large block sizes for inline dedupe to significantly affect that conservative estimation. You can do some tests with your data and make more precise calculations based on that.