Feature Request: Generate file lists of open and missing fil

[hgrams]

Corresponding support ticket: Case # 02126611

As a result of a FileCopy or FileToTape job, you can only see how many files were locked and how many files were missed. Our customers see that the task is terminated with warnings and ask why. If you want to check this data, you have to rummage through the log files to find the locked data. The missed files can not be identified after the task.

It would be very helpful if the task would generate a file list with the detected locked and not found files. This would give you a better control and a possibility to give the customer precise information on whether there is a problem in his data or in his handling of the data. The reason is to check these files. Has anybody an application always open? Or is there a file hold by an 24x7 application. Is it necessary to make a decision to save such files in a different way?

Best regards
Harald

[Shestakov]

Hello Harald,
The request looks sane, we are working on the issue to be resolved in the next versions of Veeam ONE.
Talking about Veeam B&R, how would you like to get the list of skipped files?
Thanks!

[veremin]

Most likely, you will be able to find this information in backup logs. So, custom script parsing backup logs might be temporary solution for now. Thanks.

[hgrams]

Hello Nikita,

Unfortunalety, not every customer has Veeam ONE. For that, a more convenient solution would be great in B&R. Not only the locked files but also the recognized missed files.

From my point of view, the simplest way would be a text file containing the information about the locked and missed files, e.g.

Code: Select all

[09.04.2017 01:56:01] <skipped> Error    [TapeBatchFileBackup] An error occurred during the backup: \\GZCIFS01A\Daten\WPZ\Lernende\Natalie Toggenburger\1.Lehrjahr\Februar 2017\Lernjournal 18.02.2017.docx. Reason: The process cannot access the file because it is being used by another process.
[09.04.2017 05:17:26] <missed> Error    [TapeBatchFileBackup] An error occurred during the backup: \\GZCIFS01A\Daten\customer\~$Lernjournal.docx. Reason: file could not be found or similar or something like that.

Convenient would be, if in the console message a link appears by open the text file using the OS editor.

Thanks Harald

[hgrams]

Hello Vladimir,

A qick and dirty script is already running.

The reasons of the request

1. The missing files are not listed, only the locked ones. For a detailed backup analysis, this information is mandatory in order to give the customer a precise status.
2. I think you want improve the convenience of your product. That can be a small step.

Best regards
Harald

[hgrams]

Hi,

Now, I was only able to test the update 3 to this effect, nice that now the invalid handle files are also listed in the logs.

Best regards
Harald

[hgrams]

I had the pleasure to test Veeam v10 beta 2 with the new possibilities to backup CIFS shares. I have to say that you did your homework.

Congratulations

[Dima P.]

Hello Harald,

Music to my ears, thank you for the feedback! In v10 the mentioned audit file is created only for NAS backup jobs, but we do have plans to follow the same approach for file to tape jobs in future. Cheers!

[tomnewman]

Great to hear this has made it into the product, request goes back to at least 2016 as you can see here: tape-f29/file-not-found-t36807.html#p292340

As I posted there, our file to tape job log runs to 2 million lines over 50 files, finding what files were actually missing was a pain!

[Dima P.]

Tom,

Thanks for the feedback! The plan is to roll our this audit file for NAS backup in the upcoming version and then add such functionality to file to tape jobs in vNext. Cheers!

[tomnewman]

Thanks for the clarification Dima. I clearly didn't read the post correctly and jumped the gun.

It will be great when it finally makes it. I've been working in IT for a loooong time and used lots of backup products. I have never come across another product that doesn't list what files skipped/missed/failed without having to search through enormous log files or write special scripts. IMHO it's a rediculous situation!