Hi Ana,
>Sorry for the delay.
No apologizes necessary! Thank you for the help. I appreciate it.
>Don't you have log lines for the retry that should occur at 21-Jul-2015 05:49?
I see no entry in the log file indicating job 118277 was restarted.
>Have you manually canceled the JobId 118277?
No, no one manually cancelled job 118277. I'm guessing Bacula did somehow.
Would you have any idea what would cause job 118594 to be started? Up to now, I thought it was the restarted job under a new jobId.
The above situation occurs occasionally (not frequently) for other host backups. I have not been able to figure why.
This is what shows up if I do a 'list files job=<host>:
<snipped>
| 117,865 | <host> | 2015-07-19 18:01:35 | B | I | 70 | 13,864,818 | T |
| 118,277 | <host> | 2015-07-20 18:01:39 | B | F | 1,631,292 | 311,164,701,221 | f |
| 118,594 | <host> | 2015-07-21 04:49:57 | B | F | 0 | 0 | A |
<snipped>
I did run a test to simulate what happened on our test Bacula environment. I run a backup, then while it is running I shutdown the bacula-sd daemon on the storage host. The exact same thing happened. I get the same (or similar) network error, the same 'job will be restarted in 3600 seconds' message, another job starts right away with a different jobId and the original job is cancelled. No job restart with the same jobId occurs 1 hour later.
Many thanks,
-craig