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! So 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
| 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% |
