Determining compression ratio and record size written to repository

[rawtaz]

Hello,

I have a repository server in which I can configure the record size that the filesystem is tuned for in order to make it work as well as possible with the reads and writes Veeam does to it when backing up.

I have read https://helpcenter.veeam.com/docs/backu ... ml?ver=100 which tells us that when using the WAN target setting for deduplication, Veeam uses 256 KB blocks. But then there's the compression which happens afterwards, and every place I have found says that with the standard compression setting there's around or at least 2 times compression ratio - that is, the 256 KB block would be compressed and result in a 128 KB record size being written to the repository's filesystem.

FWIW I'm using reverse incremental jobs, and I'd like to be able to determine what compression ratio is actually the case when my backups run, and thereby what the resulting record size that's written to the backup files on the repository becomes. In the end, I want to verify whether or not I can tune the filesystem to 128 KB blocks (because compression is working well enough to result in this record size) or if I have to tune it for 256 KB blocks instead (because compression doesn't reach a compression ratio of 2).

Where in Veeam B&R can I see what the compression ratio actually is/becomes when the backup jobs run? Please note that we're talking about the compression only, not taking into account the deduplication.

FWIW I am perfectly fine with, and currently use, the "High" compression ratio, hoping that this will for sure reach a compression ratio of 2. But I'd like to verify this, regardless of compression setting.

[rawtaz]

Hm, I noticed that the compression ratio actually shows when you get reports by e-mail, but I couldn't find it in the Veeam Console.

In some other jobs I have, for Windows machines (various types, such as database, application and file servers), the compression ratio is listed as almost always 1.2 for when I use the "Optimal" compression setting, and most often 1.3 when I use the "Extreme" compression setting. I also checked other jobs we have that are for Linux machines, and it's the same there. The data stored on this server is so generic that I'd definitely say it represents the normal variety of data one backs up.

To me it seems like the "about 2" compression ratio that's suggested wherever you look for this type of information is very inaccurate and not real world. It sems to be more like 1.2.