Just a heads up really, albeit a bit late in the day
Despite the Veeam upgrade process successfully migrating backup jobs from 3 to 4 I was a little surprised that the size of the .vbk && .vrb files on a fairly large set of VMs had not decreased given the improvements in 4.1. The backup jobs worked flawlessly after the upgrade but a 400GB+ .vbk file convinced me that there was a fundamental issue with the upgrade. I created a new backup job and was delighted to see the .vbk size reduced to 110GB. The .vbr files typically showed reductions from approx. 40GB to 5GB. Non-trivial savings when it comes to backup times dumping the backups to tape.
Talking of tapes, beware of advertised capacity when copying Veeam backups to tape. In simple terms you are not going to see much in the way of compression on .vbk && .vbr files because Veeam's compression is very efficient. So don't expect to get 1.6TB of backups onto an LTO4 800GB tape!
Maybe someone who is still running with old upgraded backup jobs might find this useful.
Thanks. I understand the ratios. My point was more to do with running the upgrade process and thinking all is fine with the 3 -> 4 backup jobs. My recommendation is to re-create all the backup jobs under 4 and not rely on the upgraded ones.
That's right. Until you re-create the job, you won't get the benefits of new default compression, as even if you change compression level in the job settings, it cannot be applied to the data in the existing VBK file.
Also, on your other comment - in many cases 1.6TB of source data can easily fit to 800GB tape, depending on how you create and group your VMs in the backup job, and how compressible the data store in VMs is. Our SEs has just performed a lot of experiments with that (we are going to publish the results soon), but here is the result with the current code.
We had 12 Windows 2003 VMs, 10 GB size each (120GB total).
9 VMs were made from the same template, 3 where or obtained from other SE labs.
Each VM was additionally populated with 500MB of random data.
Resulting backup file size was 23GB (for 120GB of source data, which is over 80% reduction).
