total count of failed items

[tm67]

Hi
#07786158
We are on latest patch.

We have a warning:
Processing site xxx finished with warning: Failed to backup item version: /xxx.pdf, version: 1.0, Download timeout exceeded. Total count of failed items: 18

We configured 6 retries and on each retry there is another pdf that fails / that give us a warning in the vb365 console.
After renaming the pdf on SharePoint, we dont see this pdf in the warning in the next day.
But I am not sure, do we have 18 pdfs (or other documents) that dont have a backup?

In my opinion, there should just be all documents listed in the warnings where the backup fails.
Support is currently analyzing what documents are affected, but it seems that more then 1 is affected so all of them should be visible in the warnings.
Is this something that could be optimized in a future release? Or am I understanding the warning message not correct?

Timo

[Polina]

Hi Timo,

I confirm with engineering if APIs return us the list of those items to list them in logging.

[Polina]

UPD: The total count of failed items is calculated provided per job session, i.e. each of the error messages you see in logs contains detailed information on each of the failed items.

[tm67]

Hi Polina
Thanks for the update, in my case I have 6 retries and in the history I can see on each retry a different pdf file and everytime "download timeout exceeded, total count of failed items: 18"
So I think on each retry, Veeam will try all failed items again but none of them are successful. Would be great if we can see somewhere all the failed items.
Timo

[tm67]

Update, we now have in the log file 18 files that failed to backup. And I can see each file listed with path and filename in the logfile of the job.
This corresponds with what the GUI says ("Total count of failed items: 18")

But those 18 files should be listed at once in the vb365 GUI. Maybe this can be fixed in an upcoming release?

[Polina]

Hi Timo,

I'm glad you now have the needed information, but I'll be brutally honest - we're not going to change the current logging approach any time soon. And if 18 item are quite feasible to display, it may become a challenge in larger environments with hundreds of those (when thousands of sites are protected it could easily happen).

Nevertheless, I'll think over if and how we can improve the UX based on your feedback.

Thanks!

[tm67]

Hi Polina
I totally understand; it makes sense.
Maybe there could be an improvement by referring directly to a log file.

I mean one warning in the GUI (which is also visible in an email or even in vspc) and in this warning there should be a reference to a log file and its location. In this logfile, all the failed items get listed. For better visibility, this should not be an already existing log file but a new one specific to this job-session and this warning.
Not sure if that is possible, but I think I saw other software that does it like this, and this would be pretty easy to handle. From a customer perspective.

I think the issue in my case was that we could not find the failed files listed in the logfiles. And also Veeam support only found the files after some changes in proxy.xml file. So thats what should be optimized in the future.

Timo