I have a problem processing my backup script in parallel. The scheduler runs the script at six p.m. about 10 times in parallel (one for each job). On most days this works perfectly fine without any issues. But there are days where some of them fail with the following error:
A retry is always successful. A manual call of this cmdlet is always successful. A manual call of the whole script is always successful. The problem only occures on parallel processing. There are no further logs available that I could post.
Is there something that could limit the access to the Veeam Powershell module? 10 parallel jobs are not that much in my eyes...
Hello,
as I read through the case. You state that it worked before you installed update 4.
Before I talk to support: you did not change anything in the scripts? No other (windows) updates? And could you also provide the scripts to support?
In general, I see no issue running 10 jobs in parallel if there are enough hardware resources. The only way to find out the reason why it fails is to continue with support.
We had many changes in late January, but I never had this problem in U3a and earlier. I updated B&R to update 4 (build 2399) very early after release. It must have been around January 14th or 15th. The issue must have been there shortly after this update because I changed my script on January 24th to handle this error with a try catch block and a second run of Get-VBRJob. I restored the old versions of my script to check this out.
After that we changed so much here... Starting around January 28th we migrated vSphere 6.0 to 6.7 U1, got brand new host servers, migrated to B&R U4 build 2615 and the whole B&R server went from Windows 2008 R2 to 2012 R2. This was a complete new installation but I restored the old config backup from a day before. Now we are on B&R U4a and the issue was always there. That's why I think it must be introduced with update 4.
The script is not very spectacular at all, I will post it later.
Please open a support case for your issue and post the case number here for reference. The other case is still under investigation. We were still not able to reproduce the issue.