@florent said in Backblaze as Remote error Unsupported header 'x-amz-checksum-mode' received for this API call.:
,
requestChecksumCalculation: "WHEN_REQUIRED",
responseChecksumValidation: "WHEN_REQUIRED"
I (previously as @jr-m4) just tried the patch you suggested. And I can confirm that this does indeed make the backup complete successfully!
Great work finding a solution that quicklly!
@Danp responded to similar/same issue here:
https://xcp-ng.org/forum/post/89858
@R2rho
Faulty gear always sucks. But who would've guessed that two separate systems would produce the same problems. That is highly unlikely, but never impossible.
Good luck with the RMA
So I was doing more backup-testing today.
When doing a "Full Backup" with subsequent health check enabled. The job became interrupted. However, the backup itself was successful. But it was the health check portion that failed/interrupted. This doesn't seem that it triggered the retry function.
I propose that the health checks are included into the retry criteria. But with the added granularity that when doing a retry, it only retries/continues the actual operation that failed. So it was the backup itself, then retry and continue the job from there. However, if it's the health check. Then it's unnecessary to redo the entire backup. And therefore only the health check needs to be redone.
If I'm wrong about how things work, then feel free to correct me. I'm only spit balling ideas that are based on my understanding of what I'm seeing.
Thanks
Screenshot of one of the interupted backups report:
@florent said in Backblaze as Remote error Unsupported header 'x-amz-checksum-mode' received for this API call.:
,
requestChecksumCalculation: "WHEN_REQUIRED",
responseChecksumValidation: "WHEN_REQUIRED"
I (previously as @jr-m4) just tried the patch you suggested. And I can confirm that this does indeed make the backup complete successfully!
Great work finding a solution that quicklly!
@dsmteam
Unfortunately this is the limit of what I know regarding SAML. The Google Workspace variant, was cobbled together after many hours of experimenting.
I wish you the best of luck. And if you do find a solution, please consider adding to the docs as well. As this is an area where we desperately need more comprehensive docs (as you're experiencing).
@dsmteam
Make sure to enter a newline at the end of the certificate field.
The SAML docs online are lacking. But I've written these instructions for Google Workspace SAML. Maybe this could help? And feel free to add to the docs if you happen to find a solution. 
https://docs.xen-orchestra.com/users#google-workspace---saml-supportgooglecom
@Danp responded to similar/same issue here:
https://xcp-ng.org/forum/post/89858
@R2rho
Faulty gear always sucks. But who would've guessed that two separate systems would produce the same problems. That is highly unlikely, but never impossible.
Good luck with the RMA
Well, unfortunately I got nothin... Extremely weird indeed
Given that BIOS and everything is updated to latest version possible.
First thing I do then with these kinds of symptoms, is to disable all kinds of power management and/or C-states in BIOS.
Some combinations of OS and hardware, just doesn't work properly.
If for nothing else, it's a easy non-intrusive test to do.
Update: I see that your motherboard has an IPMI interface. If the issues happen again, after you've disabled power management/c-states. You could use the remote functionality of the impi, to hopefully get some more info from the sensors and stuff.
Following; As I'm very interested in hearing more about this.
Looking a tiny bit further. The same discrepancy is present with Disaster recovery too. Being reference as Full Replication (formerly: Disaster recovery)
XO and the docs are conflicting with each other, with what the backup function should actually be called. See attached pic for example.
