I was going through some Veeam documentation recently and noticed a major improvement to the compression ratios offered in Veeam Backup & Replication v12.

Historically (pre v12), if you were to leverage ‘High’ as your chosen compression ratio for a backup job then, relative to the ‘Optimal’ setting, you’d expect to see a 10x increase in CPU consumption, for a measly 10% increase in data compression. This has changed with v12, and you can now expect to see only a doubling of CPU consumption, for a massive 66% increase in data compression!

Not to be overlooked however is that Veeam also state you can expect 2x slower restores utilising ‘High’ vs ‘Optimal’. But this could certainly prove a massive benefit for secondary backup repositories, as these are typically the ones storing backups for the longest periods of time, improving density and reducing Total Cost of Ownership (TCO).

‘Extreme’ doesn’t miss out on improvements either! ‘Extreme’ was historically a further doubling of the extra CPU required for ‘High’ to achieve an additional 3% compression over ‘High’. However, in v12 these figures are also much more optimistic. ‘Extreme’ will now achieve a further 33% compression over ‘High’, at an additional cost of 5x the CPU of ‘High’.

That last point might sound like ‘Extreme’ is more CPU hungry than before, but it’s not, and we can prove this mathematically below.

Compression Method	CPU Consumption relative to Optimal	CPU Consumption Equation	Data Consumption relative to Optimal	Data Reduction Equation
v11 – High	1000%	100% x 10 = 1000%	90%	100% * (1 – 0.10) = 90%
v12 – High	200%	100% x 2 = 200%	40%	100% * (1 – 0.60) = 40%
v11 – Extreme	2000%	(100% x 10) x 2 = 2000%	87.3%	(100% * (1 – 0.10)) * (1 – 0.03) = 87.3%
v12 – Extreme	1000%	(100% x 2) x 5 = 1000%	26.8%	(100% * (1 – 0.60)) * (1 – 0.33) = 26.8%

Testing:

It’s all good and well seeing these theoretical numbers, but you know what really counts? Real world testing! I fired up my v11 and v12 instances in my lab, built a Windows Server VM, installed SQL Server 2019 and the AdventureWorks test database, shut it down, and backed it up on optimal, high, and extreme on both VBR v11 and v12. Here’s my findings:

Source VM Size: 20.4GB consumed disk space.

Job Run	Processing Time	Processing Time Relative to v11 Optimal	Full Backup Size	Backup Size Relative to v11 Optimal
VBR v11 – Optimal	1 minute 9 seconds	100%	13.2GB	100%
VBR v11 – High	5 minutes 44 seconds	498%	11.8GB	89%
VBR v11 – Extreme	8 minutes 19 seconds	723%	11.4GB	86%
VBR v12 – Optimal	51 seconds	73%	13.2GB	100%
VBR v12 – High	1 minute 38 seconds	142%	11.2GB	84%
VBR v12 – Extreme	4 minutes 22 seconds	380%	11.0GB	83%

And there we have it, I didn’t want to prove Veeam’s percentages further with synthetic workloads at a higher density, but the point stands. With identical source data we can see improvements in processing time and compression efficiency across the board.