B2 is great as a backup store. I use it for backup.

I wouldn't use it for non backup object storage, as it's in a single data center. S3 and Google Cloud are completely different, I'm not sure on the Google specifics but S3 has data replicated across three AZs.

Isn't backing up the last place where you want zero redundancy?

I don't know about that. In my case I'm backing up a backup, so I have to lose both backups. B2 is just for the offsite copy of the backup. Like taking a tape home sometimes...

A backup has redundancy already - your local copy + the backup.

(edit: I’m talking about geographic redundancy. B2 does use redundancy inside the datacenter to protect from drive failure, etc)

In fairness backing up is the last place I want to hand over redundancy responsibility. Better I consider B2 as one part of the 3-2-1 backups than the be-all end-all

I guess what OP meant was that for backups durability is important and periods of downtime are not as crucial as for say catpicturegram.

GCS has multi-AZ replication, but also multi-region (at a premium).

S3 also does eventually consistent multi-region replication (at a premium).

If you upload an object with the same 'name' to S3, you also get a new version.

When you say 'key', do you mean the opaque object ID granted to objects in B2 which object stores like S3 doesn't have at all? I don't understand the rant here. S3 only operate by 'name' (key).

I have had no problem integrating B2 side-by-side with S3 and GCP in the products I have written. Their high-level models are largely compatible.

S3 versioning is optional and off by default. Writes (including rewrites) to S3 are also atomic, so you’ll never see partial writes.

Ah, fair enough. I have oddly enough never in my life written to the same key twice, so I hadn't noticed it was off by default for S3.

Just to clarify you statement about atomicity: All writes to S3 and B2 are 'atomic' (and B2 can also verify the hash and reject on failure for an extra layer of security). The difference you mention is just that you can superficially "disable" versioning for S3, so that each key only stores one object version at a given time.

The only difference to the upload when S3 versioning is disabled is what happens during the metadata update: With versioning, a version is appended. Without, the version is replaced.

For B2, simulating disabled versioning is two operations: Upload a new object, and delete the old one. As long as the object is only referenced by name, this will also be atomic.

S3 allows you to turn versioning on and off for a bucket; my understanding is that B2 does not.

Yeah, that's correct. You have to delete old versions manually after upload if you want to simulate an "overwrite".

It would be quite simple for backblaze to implement, though, so I guess it might come as a future option.

Why would you need a separate ID other than the actual filepath key? (and a metadata version number if you have versioning available)

B2 doesn't have metadata version numbers, but instead use the globally unique file identifier to refer to specific versions. When you list file versions, you're presented with file ids rather than version numbers.

It's only slightly different from the name+version approach, but I personally like the concept of unique identifiers better. It feels nicer.

I'm on DigitalOcean, and I love it, but I use B2 for backup because it just naturally seems safer to have the backups with a different company. It is great for that. I found the object upload a bit weird / different, but I appreciated how it stops you from shooting yourself in the foot by default, rather than the other way around.