Optimizing suspicious incremental backup size alarm

[afang]

Hi. One of the most important alarms I believe I can get out of Veeam ONE is the suspicious incremental back size alarm, but my infrastructure presents some difficulties.

1. It consists of >1000 VMs, thus has many jobs. The amount of VMs are constantly changing too, albeit at a slow pace.
2. Looking at the Data Protection view, my jobs have different types of workloads with different durations -- lasting seconds, minutes, hours, overnight, and even a monthly job that can run an entire day.
3. A variety of VM sizes, ranging from small file servers to huge databases. These VMs can be in the same backup job too, so something like one VM can exceed a backup size condition by 300% while another in the same job can actually be below the condition %.

So as a result I get thousands of red flags every day. I tried increasing the analysis depth and the conditions to a decent %, but unfortunately there is no one-size-fits-all solution for this. I know I can add rules for individual job names, but is a way to expedite this process for someone like me who has a large number of jobs, most of which I'm not sure what condition %s to set?

Thanks.

[jorgedlcruz]

Hello, That is very interesting topic, and I quite agree that with so many different jobs it would not be efficient.

As you mentioned, you can assing some specific alarms, a clone of the suspicious, to a few different jobs. It might not be the best solution, but at least you can tune every alarm according to similar values.

Let me dig internally to see if I can find something more advanced, but so far the faster solution to me is cloning the alarm, and assing same type more or less.

Thank you!

[RomanK]

Hello Allen,

Suspicious incremental backup size uses simple math: it takes the latest (3 by default) restore points and evaluates their size. It fits for the most common scenarios while organizing it for the huge infrastructure could be challenging.

For example, restore points for daily backups created on a business day can be larger than restore points created on a weekend. Comparing 3 points for Saturday, Sunday and Monday, the last point is expected to be larger in size for natural reasons.
By the way, the number of VMs or workloads as well as job duration does not affect the alarm logic.

Having that, for the current release, the answer is in the question and some infrastructure (re)organization is probably required. You are the only one who knows your infrastructure better than anyone but I'd probably split the alarm by backup server and job types. Then I'd try to play with job names and Job name and Exclude jobs fields to split the alarm furthermore. After that, I'd probably try to reorganize the backup jobs, like avoiding adding small file servers and huge databases in the same job.

If have some ideas about what could potentially help you to organize these alarms please share.

Thanks