Reason/s behind big changes in compression rates?

[r.mckeon]

I'm wondering if someone can give me some pointers and hints on to where to look for when it comes to finding the cause of big changes in compression ratios and amount of read data in backup jobs. This is the situaiton:

Last week, I recreated some backup jobs, almost from scratch (re-added the VMs with new reference IDs as I had to install a new vCenter). This meant that a full backup had to be taken on the first backup run. All went okay, and they've been running normally for a week. Then, since on particular day (last Thursday to be exact), ONE of the jobs starting acting up. The job backs up a file server VM daily, and the average compression ratio is around 3.5x . Since Thursday (and no, nothing changed on the server, vCenter, etc) the compression ratio has been playing around sometimes showing as 62x, sometimes >999x, sometimes 38x. Always very different and always way more than the usual average.

Also, another strange thing is that usually the Read data counter on this VM marks at around 3 - 5 GB. Suddenly its marking in the 40GB, and in one instance 380GB!! The compression rate increases proportionally along with the amount of data written. Now I am aware this is a file server but I checked with the users and nowhere near that amount of data was moved in one day. Also, the same symptoms are seen in the weekend, when there is no activity on the server.

Now this is the strange part...this has only happened on one job. No changes where made from my side on the server, Veeam or VM infrastructure. Can you help point me in the direction I need to start checking to see what's the reason for this drastic change? If you're wondering why this is bothering me: a) this is not normal behavior so something is off and b) the duration of the job has increased drastically, due to the much larger amount of data being read by Veeam.

PS. I am using Veeam B&R 7.0 Patch 4
PS. I did not open a support case as I do not see this as necessarily a technical issue, just a lack of understanding on my part on how Veeam works

[Vitaliy S.]

Did you recently add or remove/relocate any data in the VMs that have high read rate?

[r.mckeon]

Did you recently add or remove/relocate any data in the VMs that have high read rate?

The file server is in use on weekdays but nowhere near the amount of Read data was removed or relocated on the VM, very strange. Also, I noticed something else. The compression and deduplication ratios shown on the email success reports I get per job from Veeam B&R are different from the ratios shown in the History page in the client application. Which ones should I take notice of?

[veremin]

Are there any specific activities being performed inside VMs on regular basis, such as, defragmentation, antivirus, etc. that might affect the number of changed blocks? Thanks.

The compression and deduplication ratios shown on the email success reports I get per job from Veeam B&R are different from the ratios shown in the History page in the client application. Which ones should I take notice of?

You mean if you take a look the statistics of the latest job cycle (double-click a job), the numbers deduplication/compression rations are not the same as those shown in the latest email report?

Thanks.

[r.mckeon]

You mean if you take a look the statistics of the latest job cycle (double-click a job), the numbers deduplication/compression rations are not the same as those shown in the latest email report?

If I double-click a job to look at statistics I see for example Transferred Data: 390.9MB (>999x)

On the email report of the same job, I see Transferred: 390.9MB , Dedupe 3.8x , Compression 1.2x

[veremin]

The numbers should not differ from one another. Please, contact our support team and let them find the root cause of this behavior. Thanks.

[r.mckeon]

Ok but what is the number shown in brackets supposed to represent? Deduplication? Compression? Both?

[foggy]

This is the compression rate. Also, please note that compression and deduplication values from the Backup Report relate to the backup file size (in relation to the total data size), not the data read and transferred during the job session.