Backup Copy Jobs failed with no error

[ejenner]

Can anyone explain what the issue is here with these jobs which have failed without any error? I've got two.. The only unusual thing about the jobs being targeted is that they run 4 times a day.... but there are other near identical jobs which don't result with a failure.

[wishr]

Hi again EJ,

This means the job failed during the previous run and the status will be updated once the current backup copy interval ends. So if you'd like to identify what was wrong and why it has failed - please take a look at the previous run.

Regards,
Fedor

[arun.kr]

Hi,

Which version of Vbr are you using?
I am using 9.5 update 4, Yesterday, I also had same issue but my server was very so rebooted it, thought due to slowness it would had happened.
If tonight see the same behaviour, backup completed successfully but showing as failed in results column will open a case.


Thanks
Arun

[wishr]

Hi Arun,

My comment applies to your case as well. If any assistance with the investigation is required - please open a case. Our tech. support will be happy to help!

Thanks in advance,
Fedor

[ejenner]

If that's the reason... then why... if the job fails then it should say failed, but if it has completed successfully since it should say it has completed. What is the logic going on here?

[wishr]

It's a result of the latest session that lasts from the beginning until the end of the corresponding copy interval, it's not a status of the job itself - it's the status of the job "run". The current "run" is not finished yet, so the status of the previous "run" is still shown and will be updated once the current "run" has finished.

Regards,
Fedor

[zadrian]

I think this is a bug in 9.5u4 as this was not the case in 9.5u3 or earlier.

Even sometimes when retrying failed jobs, it would send another "failed job" header but all content says job succeed.

veeam-backup-replication-f2/weird-faile ... 58182.html

[wishr]

Hi Zadrian,

It's not related to the issue mentioned in the thread you linked. The behavior of the copy jobs and underlying sessions is different and it works exactly as I explained above - this is a by design behavior, that is logical. If the current session is still running, the status of the previous one is shown in the UI. Hope it makes sense.

Regards,
Fedor

[ejenner]

It's not really all that logical because the 'Last Result' column describes a state which has no corresponding reference point. i.e. the schedule is described as 'continuous'. So if 'Failed' describes the result at a point in time, you would have to know which point in time that result refers to?

The problem is how we react to the word 'Failed' in relation to defined jobs. If you see the word 'Failed' you have to investigate and find out what failed. If the current log and none of the available information will explain the failure it starts to look like a fault in the product. A 'continuous' process can't be both continuous and ended with a result at the same time.

[wishr]

Hi EJ,

I understand your point. Let me explain a bit more.

"Continuous" means the job has a continuous schedule, starting a session/job run continuously, in accordance with the intervals configuration. Each session has a reference point that is mentioned in a session/job run details that could be checked. Simply press the "< arrow" button on the keyboard to switch from the currently active session to the previous one - that should help you with the investigation: you can check the log, event timestamps, etc. You can also take a look at the "24 hours" view to get the same information.

We do not update the status instantly once the latest data is transferred because the data transfer has ended, right, but the session is still running and can fail in certain circumstances, for example, if one of the B&R components involved into the backup copy process fails even if the job is idle.

If there are any suggestions on how exactly the column/status names can be improved in order to make the current UI more clear - just let me know and we'll see if we can apply your suggestions in later versions.

Regards,
Fedor