Job failed see logs

[Zew]

Hey all,

So interesting enough I got a new error, failure email alert. To my surprise it provided literally ZERO information as to the cause. "10/10/2016 3:24:17 AM :: Job has failed. See logs for details."

Now not wanting to seem like I did nothing, I sure enough found out where the logs were stored.. I was a little confused to exactly which log file to check, figured the alert above would at least give me that... nope.. great..

So from Agent.BackupJobName.Source

Code: Select all

"
[10.10.2016 03:26:34] <  6900> ====================================================================================
[10.10.2016 03:26:34] <  6900> {
[10.10.2016 03:26:34] <  6900>   Windows agent.
[10.10.2016 03:26:34] <  6900>   Path to the executable module: C:\Program Files (x86)\Veeam\Backup Transport\x64\VeeamAgent.exe
.....
"

O...k, nothing... next...

Agent.BackupJobName.Source.IssueVM.Disks (As only one of the three VMs on this BCJ failed)

Code: Select all

"
[03.10.2016 02:10:27] <  4716> cli| Destroying connection pools. ok.
[03.10.2016 02:10:27] <  4716> cli| The agent session has finished successfully.
[11.10.2016 10:22:23] <  9864> ====================================================================================
[11.10.2016 10:22:23] <  9864> {
[11.10.2016 10:22:23] <  9864>   Windows agent.
"

Again Nothing, this is starting to bug me...

So finally...

Job.BackupJobName.BackupSync

Code: Select all

"
A wack load of Errors
[10.10.2016 03:24:16] <01> Error    Timeout expired ("10800 sec") (Veeam.Backup.SSH.SCPException)
[10.10.2016 03:24:17] <01> Error    Task 'Kamino' was not completed. So it will be failed
"

So it again appears to be cause of my flaky connection to my cold site. Instead of wasting my time and Veeams Supprt time, I decided to just re-sync the job manually.

Here's the kicker, The failed VM proceeded just fine (the failed one, but the other two that completed successfully now are stuck "waiting for a new restore point" So the whole job is stuck @ 33% (only 2 other VMs need to be processed.)

The Take aways.....

1) Exact log to look for info would be nice at the main history window.

2) What does one do in this case, my re-sync is once a week, I don't really want my BCJ stuck @ 33% for an entire week...?
I guess I'll just have to re-run the primary job to obtain these new restore points and let that BCJ complete on its own.. (Given my connection doesn't flak out, like it always does)

[PTide]

Hi,

two that completed successfully now are stuck "waiting for a new restore point" So the whole job is stuck @ 33% (only 2 other VMs need to be processed.)

That's an expected behaviour since the latest restore points for those two VMs have just been transferred. The BCJ will wait for new restore points for these two VMs until the sync interval ends, and will start a new one.

Exact log to look for info would be nice at the main history window.

The main history window was designed to keep only basic info, full logs are intended to be read by support team. The fact that the re-run allowed you to process the failing VM probably means that there were problem with the connection, indeed. Please contact support team for a deeper investigation.

Thanks

[Zew]

Hey PTide,

Thanks for the reply.

1) I thought maybe it would constantly now rotate, between the failed VM and the non failed VM between cycles. But checking it now after the weekend, shows all Green for all VMs in that Job. So sweet.

2) I don't expect any info on teh consol, but I at least expect it to tell me WHICH log to look at.
Eg. 10/10/2016 3:24:17 AM :: Job has failed. See logs C:\LogPath\Job.BackupJobName.BackupSync for details

So you know, I don't have to look through who knows how many log files to find out which one I exactly need to investigate. That was the point I was trying to get through.

[foggy]

So you know, I don't have to look through who knows how many log files to find out which one I exactly need to investigate. That was the point I was trying to get through.

Your point sounds reasonable, though we do not encourage our customers to look into logs, but rather provide the entire logs bundle to support engineer who knows where to look.

[Zew]

Then it might as well say, Job Failed. Call Support.