Jobs fail but after 4th retry completes ok

[Chill]

Hi Veeamers - first post so be gentle!

Have been using Veeam for quite a few years and am currently on v9. Up until a major primary storage crash (hosting among other things VM datastores) a few weeks ago, Veeam was behaving normally. Due to the nature of our storage fault (which is independent of the Veeam repository used), I shutdown the Veeam service as jobs would have failed during this outage. Once the storage issue was fixed, Veeam was restarted as normal however since then each job fails x4 times, then succeeds on the 5th attempt.

A failed job report shows two entries which identify the issue:

Job summary
1.Error: Cannot proceed with the job: existing backup meta file 'xxxxxxxx.vbm' on repository 'Backup Repository x' is not synchronized with the DB. To resolve this, run repository rescan

Job details per VM
2.Task failed Error: Cannot complete login due to an incorrect user name or password.

The repository has been re-scanned and the credentials are correct and haven't been changed.

I haven't yet logged a service call with Veeam (although that will be next) but wondered if anyone had encountered anything similar?

Thanks

Chris

[foggy]

Chris, am I understanding right that now everything is back fine, your jobs are running and you just want to investigate the reasons of the first four failures?

[Chill]

Hi, everything is fine until the next schedule runs then the same thing happens again. I have logged a call with support (Case # 01754262) but baffled as to what could cause this.

Thanks

[foggy]

Job logs should tell the reason of the failures, so let's wait for them to be reviwed by our engineers.

[Chill]

Update: After raising an SR, several reasons for this weirdness were investigated and a big thumbs up to Veeam support for their diligence. As it turned out, there was an element of 'user error' as the fault came down to an old Veeam server which had been decommissioned (supposedly) but was in fact running the VBR service after an unplanned reboot. This only came to light after some internal investigation. This particular server was hidden behind a load balancer to complicate matters even further.

It took a while, but we got there in the end!