Using the change above, restic spits out an error: Fatal: unable to open config file: Stat: Access Denied. Reading various documentation, I’ve tried to use this instead (in addition to changing environment variable names from Backblaze to AWS specific): Previously I had restic repo specified like this: I’ve tried to start using S3-API on Backblaze, but can’t do that. As asked by already, is there somewhere some resources as what could go wrong when using Backblaze backend without S3-compatibility layer? I’ve been using Backblaze as a storage backend for years now and when I started using it there was definitely no warnings. If I need to move from B2 to S3, is there a way to convert my existing repo or would I need to back everything up again if I change to S3? What is the risk of continuing to use the B2 API? Data corruption? If so, does 'check’ catch it or would I need to do “check -read-data”? Is this a short term problem and is there an updated B2 library now that provides the error handling? If so, is there a plan to update restic with the new library so B2 can be fully supported? The docs say “Due to issues with error handling in the current B2 library that restic uses, the recommended way to utilize Backblaze B2 is by using its S3-compatible API.” I saw this warning and I wanted to ask for a little more detail to decide if I need to switch to using the S3 API. I have been using the Backblaze B2 API/backend and have a lot of data in my current repo in a B2 bucket.

I’ve been using restic successfully for a while.

Backblaze s3 compatible