Backup failing: “Path cannot be null” and “TLS warning: SSL3 alert write: fatal: bad record mac”
has a more extended log that shows an error similar to yours, but just before that another one that wouldn’t be logged ordinarily, because it’s at Retry level. The poster possibly had added a –log-file configured to –log-file-log-level=Retry or more (Profiling is highest, and I use it, but output is huge). Verbose is in-between. The main problem (for privacy) is it can have source path names in places. Logging to file is probably the easiest way to get a big log. Live log is best done for one screen-full. Getting too big a file for your usual editor/viewer can be solved with glogg or EditPad Lite or others.
You can see whether you tend to do retries (e.g. for network errors) from job log’s RetryAttempts. Setting –number-of-retries low on a job you care less about may be a good way to unearth bugs…
That’s been what I’ve been doing lately, on redundant backups so I can afford to break and debug.
2.0.4.5 - The process cannot access the file because it is being used by another process
is my quote of the interesting double stack trace with commentary. I wonder if one led to the other?
The emails don’t attach full logs, but seem to include some relevant sections determined somehow.
2.0.4.5 - The process cannot access the file because it is being used by another process
looks like it might be from an emailed report, due to the Log data section. Instead of the usual log, looking similar to the ones in the web UI with a bunch of stats, a failure email has more failure data.