In my experience, the CLI will return non-zero exit codes on errors. In that way, you know that something went wrong. Isn’t that good enough? Or do you need visibility on EXACTLY what the error was?
Consider this:
Failed to upload the chunk 2dcef97eac6562136f35c411e15a1ed7b193cc35ff7950e4f1b42ea5059297dd: Put https://XXXXX.blob.core.windows.net/XXXXX/chunks/2d/cef97eac6562136f35c411e15a1ed7b193cc35ff7950e4f1b42ea5059297dd: write tcp 192.168.1.125:59725->52.191.176.36:443: write: broken pipe
Uploaded chunk 353940 size 2489875, 10.07MB/s 20:18:06 70.1%
Uploaded chunk 353941 size 3310368, 10.07MB/s 20:18:06 70.1%
Uploaded chunk 353942 size 2714835, 10.07MB/s 20:18:05 70.1%
Uploaded chunk 353943 size 2139599, 10.07MB/s 20:18:05 70.1%
Incomplete snapshot saved to /Volumes/Storage/.duplicacy/incomplete
Office-iMac:Storage jeff$ echo $?
100
Office-iMac:Storage jeff$
Contrast this with a successful backup:
Office-iMac:office-db jeff$ duplicacy backup -threads 2
Storage set to azure://XXXXX/XXXXX
Last backup at revision 20 found
Indexing /Users/jeff/local/office-db
Loaded 7 include/exclude pattern(s)
Backup for /Users/jeff/local/office-db at revision 21 completed
Office-iMac:office-db jeff$ echo $?
0
Office-iMac:office-db jeff$
Note that in the error case, the exit code was 100
(non-zero == error for Linux), where it was 0
in the success case.
Is this good enough, or do you need something more for this?