case #04545115. We are unable to export logs for specific jobs and for the Veeam server components. 'Log export failed' error. The log of the logexport reports that it cannot find the file, while windows explorer can open the mentioned file fine.
We tracked it down by the file path of some logs longer than 256 characters. The log export of Veeam B&R can't cope with this. Strange thing is that Veeam B&R itself creates this long path itself. When creating/editing a job it accepts a job name of quite some characters. Even if you specify d:\logs as the location of the log files, the path can become too long for the logexport. When exporting the logs for a support call it fails with the mentioned error.
So why is Veeam B&R unable to access these long path names, while Windows Explorer itself is capable of accessing these files fine. Veeam B&R itself creates the files with these long filenames and is able to write to them. So it looks like only the log exporter component has a problem with file paths consisting of more than 256 characters.
In fact, I see this issue for the first time and it seems to be quite strange because by default logs are located in C:\ProgramData\Veeam\Backup. You can change default log folder location by adding "LogDirectory" value to the registry but I assume that you didn't change default settings. My only guess is that some backup jobs could have very long names and it would make our log exporter to fail because the path to a job log consists of log folder path and backup job name.
Anyway, it would be best to continue working with our support team to get a clear explanation of this behavior.
I did change the log location to d:\logs so even shorter. However, support suggested to change the job names to shorter names, but that’s just a workaround and not a solution.
I'd suggest to ask our support team to look a bit deeper into the issue, probably it would be possible to think about the fix in one of our future versions. For example, starting from Windows 10 (1607), MAX_PATH limitations have been removed from Win32 file and directory functions.
Support acknowledged it's a known issue in the export log component. The only workaround currently is to shorten the job names so that the total path is less than 255 characters. Since we are using backup immediate copy jobs, the path can be quite long, since the logfilenames consist of the backup copy job name and the source backup name.
Ok, I'll ask our engineers to investigate the issue a bit deeper in order to understand if it can be fixed in our future releases. I'll update the topic once I have more details.
Yes, we discussed your request internally. In theory, it's possible to fix the issue for logs export procedure however the implementation seems to be more complicated than I thought. Anyway, the request is noted. I cannot provide any ETA as it depends on priorities of other enhancements that we're going to deliver in future releases.
reports that it cannot find the file, while windows explorer can open the mentioned file fine.