Feature Request: Include more granular job details and times in emailed reports

[absentpetti]

Currently the emailed reports include two main times.
The first being the overall job start and end times.
The second being each individual servers times within that job.

What is not really visible in these reports is the breakdown of the times further than that.
For our helpdesk to understand why a job was delayed requires jumping into the Veeam console within 24 hours to see the most recent statistics/report. To then understand that right it was waiting for X minutes for resources, Y minutes for merging, etc. etc.

We have also noted times where the overall Job itself appeared to take a lot longer to complete than its constituent servers within the job did.
So it is not clear, even in the Veeam admin console, why the overall job itself reported such long running times when the servers that it actually processed finished hours and hours ago.

We would like the reports, esp emailed ones, to include a more granular breakdown of the Jobs and Servers so that our helpdesk can use this information to understand whether it is expecting or an anomaly.

[veremin]

How granular do you expect the email report to be? Literally the same as the log you can see by opening a session of a particular job in the backup console? Because with detailed information on each job, the report could turn into a mess or an unreadable wall of text.

After all, the main idea of the daily report is to provide very high-level information that gives a general understanding of the success or failure of backup activities, while for details you still need to go to the console itself.

Thanks!

[absentpetti]

Unfortunately, even the console itself is a little vague on details in some areas.
For instance, I have been investigating why Veeam is reporting a "read" of disk speed well below what we know the disk is capable of.
Monitoring the job in progress though I was able to identify that for approx. 1-hour Veeam was reporting a speed of 0, whilst the disks in question were showing significant activity. So, it appears that there is some action/activity occurring that is not presented in the consoles job report that is skewing the average disk read speed to below what the true speed is.

Currently the reports are a little too high level. Like the backup took X hours but the Job itself continued working for several more hours. If the backup itself was completed what was the job doing for that time? Reports like that raise eyebrows and force the helpdesk to dial in and review the console for potential issues. Were this time accounted for in the report we would not have to chase it up.

The level of granularity could also be optional/configurable for those who want more concise versus more detailed reports.

As to what granularity we would value. Spit balling some ideas:
1. If the backup itself is completed but the job is still doing "things", outside of the backup of servers itself, this should appear as a line item in the report.
2. The aggregate time of all line items in the report should match the time of the job itself with minimal to no missing time unaccounted for.
3. Scanning/reading/diff check of the source against the destination. Note the time spent on the source scan.
4. Transmission time/saving to destination. Note the time taken to transmit/save to destination.
5. Merging. Note the time taken to complete any required merges.

Just having these as columns for each server (row) in the report would allow for us to understand, at a glance, why a specific job had the duration it did without having to go trawling through log files. Or the shortly lived 24 hour console accessible report.