Print more error info for minio
Could help debugging #134 since Minio should be able to handle retrying... The ErrorResponse type contains a lot more info.
Since it's no fix and just helps finding the issue, I created the PR as draft. It may help tracking down Minio issues in the future or help the user with more verbose errors. Feel free to close this if there is no need.
Were you able to test this? I like the idea, but I am not sure if it actually makes a difference because of the following: if you're using the %w verb in the fmt.Errorf template, an error type is expected. The error interface is implemented on ErrorResponse, but it just returns the Message when calling Error, which is probably the very same result as we have right now. I.e. we'd be casting the error to an ErrorResponse and back again.
I think the proper approach here would be casting to an ErrorResponse and the manually constructing the error message, populating it with relevant information ourselves.
I did not experiment with it yet, since I wanted to wait for your input as you said (in the underlying issue) that you will have a look yourself too.
I can try to provoke a failed copyBackup operation. Idk yet how I would let it intentionally fail (as I would prefer to do that with a real B2 bucket to see what info is available). Perhaps setting the permissions too low so it fails, we'll see.
I will update the draft accordingly in regards to the error info printing.
I can try to provoke a failed copyBackup operation
The easiest way I can think of would be to point the setup towards an inexistent bucket.
You were right, it had to be unpacked.
It now looks like this when using the non existant 'invalid-bucket':
time="2022-07-22T16:00:44+02:00" level=error msg="Fatal error running backup: copyBackup: error uploading backup to remote storage: [Message]: 'The specified bucket does not exist: invalid-bucket', [Code]: NoSuchBucket, [StatusCode]: 404"