Skip to main content

Hi All,

I am new the the community and fairly new to Veeam and was wondering if anyone would mind sharing their own opinions and/or pitfalls  experienced using the Inline Entropy Analisis feature?

My organization uses Veeam for Vsphere backup and DR and I have been asked to gather information prior to using in production.   I sounds great but from what I’ve read so far it has its limitations. Has anyone experienced any performance issues with backups or any other gotchas?   Have you found the feature useful?  Any feedback would be greatly appreciated.

Thank you!

Hi @lenhartj -

Absolutely don’t mind sharing. You are indeed correct. Inline Entropy engine does have limitations. I wrote about the Inline Entropy engine in a post here on the Hub a few months back. For my experience and most of the limitations with it, I recommend reading through it:

But, don’t fret! It is going to be getting a face lift soon! Veeam Product Managers will be updating it to help with malware event forensics and analysis. When this will be released is tbd. But, for detailed info directly from the Veeam team, follow the below thread in the Forum:

https://forums.veeam.com/veeam-backup-replication-f2/veeam-12-1-suspicious-files-t91348-120.html#p519783

 

Hope this helps. Let me know if you have further questions.


We are just beginning to implement it with many other changes.  I have used it in my homelab without issue to performance at all leaving it on the Normal settings.

In production our servers are more powerful so I cannot see it affecting performance.  I also want to use the Splunk App too for some of this stuff.


If and/or when you do implement this security feature in your environment, be aware each of your Jobs upon first run after implementing will NOT use CBT, so backups will take as long as they did upon initial run. This is so Veeam can read each VM disk and create a RIDX file on the Proxy for future job run comparison purposes. You can read more about this in the Guide:

https://helpcenter.veeam.com/docs/backup/vsphere/malware_detection_inline_scan_hiw.html?ver=120


Hi @lenhartj -

Absolutely don’t mind sharing. You are indeed correct. Inline Entropy engine does have limitations. I wrote about the Inline Entropy engine in a post here on the Hub a few months back. For my experience and most of the limitations with it, I recommend reading through it:

But, don’t fret! It is going to be getting a face lift soon! Veeam Product Managers will be updating it to help with malware event forensics and analysis. When this will be released is tbd. But, for detailed info directly from the Veeam team, follow the below thread in the Forum:

https://forums.veeam.com/veeam-backup-replication-f2/veeam-12-1-suspicious-files-t91348-120.html#p519783

 

Hope this helps. Let me know if you have further questions.

Yours was one of the articles I read during my research and it was very informative.  Thank you for writing it!


If and/or when you do implement this security feature in your environment, be aware each of your Jobs upon first run after implementing will NOT use CBT, so backups will take as long as they did upon initial run. This is so Veeam can read each VM disk and create a RIDX file on the Proxy for future job run comparison purposes. You can read more about this in the Guide:

https://helpcenter.veeam.com/docs/backup/vsphere/malware_detection_inline_scan_hiw.html?ver=120

Very nice summary of how it work, thank you again!


No problem. Let me know if you have further questions.


click me


I haven’t experienced any performance issues with it.  That said, every alerts I’ve gotten appears to be some form of false positive, usually due to some form of (legitimate) encrypted data on the VM.  That said, I’d a good to have feature, but I hope there’s some better reporting/log analysis developed around it with time.


I don’t want to enable it quite yet as I fear CBT being reset would make my backup window take WEEKS.

Perhaps if I could enable 1 job at a time, and slowly work my way down the list as many of these large file servers have been separated from each other. 

 


Comment