git-annex/ tips/ using Backblaze B2

For using Backblaze B2 as a special remote, there are currently three choices:

- Using rclone
  (Actively maintained)

- Backblaze B2 supports supports the same API as Amazon S3, so git-annex's built-in S3 special remote can be used with it.

  However, it needs S3 version 4 signatures, which are only supported by git-annex 8.20200508 and newer.

  Here is how to set up the special remote:

        export AWS_ACCESS_KEY_ID=$appKeyId
        export AWS_SECRET_ACCESS_KEY=$appKeySecret
        git annex initremote backblaze type=S3 signature=v4 host=$endpoint bucket=$bucketname protocol=https encryption=$encryption

  Remember to replace:

  - `$appKeyId` and `$appKeySecret` with the values displayed by B2 when you created an "Application Key".
  - `$endpoint` with the B2 endpoint to which your account has an affinity.
    - An easy way to find the correct value is to create a temporary bucket in the service's web UI, and then use the "endpoint" field displayed for that bucket (before deleting the temporary bucket!).
  - `$bucketname` with the name of the bucket you wish to use
    - This is not the opaque B2 "Bucket ID".
  - `$encryption` with the encryption setting you want git-annex to apply to the files it stores in the bucket.
    - This is unrelated to the B2 server-side bucket encryption setting.

  If a bucket with the specified name does not already exist then git-annex will attempt to create it. If the access key provided does not permit bucket creation then the `initremote` command will fail. The bucket will be created in the unchangeable region that the access key's account is pinned to, with infinite versioning enabled and server-side encryption disabled. Given that you're probably using some form of git-annex encryption, and that files with server-side encryption enabled are not included in a server-side bucket-level snapshot, you may wish to leave the server-side encryption disabled.

- A dedicated special remote, https://github.com/encryptio/git-annex-remote-b2
  (Last updated 2016)

At this time it's not clear which is better, so if you find one works better than the other, please comment below.

Key permissions

I tried to use Backblaze B2 using the second method, and tried different application key permissions. Hopefully I can save your time if you’re going to use this special remote.

In order to init a B2 remote, you should create a key with the ability to read & write all buckets, and you must create a new bucket using git-annex (by setting a unique name in `bucket=`). If you create an empty bucket using Backblaze's web UI, then use that bucket for `git annex initremote`, you will receive this error message: `(InternalException (HandshakeFailed (Error_Protocol ("expecting server hello, got alert : [(AlertLevel_Fatal,IllegalParameter)]",True,HandshakeFailure))))`.

In order to enable a B2 remote, you need a key with read & write permission to the bucket you're using. If you created a key with only read permission, you can’t use `git annex get` on that remote.

Comment by aaa — Wed Oct 29 14:05:27 2025
Rclone B2 vs S3
I've been using the rclone B2 special remote for a while now, and it seems to produce a very large number of Class C (the most expensive class) transactions while performing certain operations (uploads & dropunused, at least). I just started using the S3 special remote today, and while I've only uploaded so far, it seems to produce far fewer Class C transactions (after uploading a pretty large number of files, I'm only seeing 13). If cost is a concern, that might be one reason to prefer the S3 special remote. That said, this is mostly anecdotal. Perhaps someone else might chip in empirical data or check out the code to back up these observations.
Comment by emi — Wed Oct 29 14:05:27 2025
Comments on this page are closed.