They did an AMA on Reddit a few months ago[0]. I remember this AMA in particular because they thoroughly explained why they designed some features in certain ways. Overall they said their target customers are the ones with absolutely no IT knowledge.

I guess this part from one of their answers fits your complaint quite well: But here is the thing -> YOU can work around this problem, the naive customers CANNOT. Honestly, they are too computer-illiterate. But even computer illiterate people deserve to have their files backed up, and they are the target market for Backblaze Personal Backup. [1]

From this point of view, I guess a "delete" button could be fatal for some of the older folks out there. But I don't use Backblaze, I don't know if my comparison makes sense and we both talk about the same thing. The Reddit quotes refers to their "Backblaze Personal Backup".

[0] https://www.reddit.com/r/IAmA/comments/b6lbew/were_the_backb... [1] https://www.reddit.com/r/IAmA/comments/b6lbew/were_the_backb...

I'm the Backblaze employee that wrote that quote. :-)

> YOU can work around this problem, the naive customers CANNOT.

That was specifically in response to a Backblaze Personal Backup feature request.

> I guess a "delete" button could be fatal for some of the older folks out there.

Just to be clear, Backblaze offers two product lines: 1) Backblaze Personal Backup which is designed to be simple and easy to use, and 2) "Backblaze B2" which is designed as a toolkit for programmers and IT people. So in this particular case, we SHOULD have a "delete all files" button (for IT people), and we know this currently sucks (it's on a roadmap to add the feature).

You can select "some group of files" (like one folder) and delete them all at once from the web GUI, but if you have like 1 million files (which is a perfectly reasonable and normal backup) the web GUI will "time out" and fail to delete all the files in one operation.

The current recommended work around is to write a very short "life cycle rule" in the web GUI that deletes any/all files 1 day after it is uploaded and let it run for 24 hours and come back to an empty bucket. Yes, I know this is lame. https://www.backblaze.com/b2/docs/lifecycle_rules.html

To paraphrase my quote about computer naive users, the reason we don't prioritize this particular feature higher is the IT people (like yourself) are capable of doing the crazy work arounds like spinning up an EC2 instance. :-) But we will get to it, I promise!

In our defense, we have 5 open programmer job recs, and 5 open IT job recs, and we're having trouble finding enough (qualified) people who want to come help us build these features for customers. If you want to work in a really fun employee owned business in San Mateo, California where you can bring your dog to work, please come and join us! https://www.backblaze.com/company/jobs.html

There are all sorts of ways to created a delete-bucket button that avoids tech-illiterate fat fingering. Like simply burying it in options. Requiring end user to make a billion individual requests is almost as bad as making me call a number to delete my bucket.

I’m voicing this here because I was surprised at the UX. I was happy with my backblaze experience otherwise. My bill was incredibly cheap for the amount of data and access I was using. I’d consider using it in the future for things we generally default to S3 for.

Your casual substitution of "older folks" for "people with no IT knowledge" is ageist ignorance.

We all know the type of people OP is referring to. Pretending they do not exist does not really make anyone's life easier, especially when the discussion at hand is literally about trying to make their life easier by reducing the possibility of a mistake.

The people OP is talking about are ones who are not computer literate. Those people can be of any age. There's just no reason at all to related it to age.

With all due respect, if we were to plot age vs computer literacy, there would be a very high negative correlation.

Be that as it may, by jumping ahead, you miss out on the younger computer-illiterate, and alienate the older computer-literate.

There is zero benefit to over-generalizing that I can see, and it is very likely to lead to errors.

Or perhaps an overbroad generalization? If you work in adult day health dealing with backblaze personal backup IS in fact beyond the abilities or interest of many of the folks there.

Or do you not have personal experience working with the very elderly? The very elderly engineers are more into electronics (physical) and can run rings around younger folks on older electronics (repair / vacuum tube testing etc). But I've not seen high levels of interest in things like Backblaze personal backup API's.

"Very elderly" != "older" (folks).

People of all ages vary in their IT abilities, and IT abilities are obviously what matters in dealing with issues like backup.

There's just no reason to bring up age at all.

I'm 67 and did not take offense at the comment.

Very old folks can start to lose decision making capabilites. It has nothing to do with IT knowledge. It's why mostly old people fall victim to email and phone scams and refuse to believe the truth even after you show them mountains of evidence.

Is that ageism?

The ones I know that has lost money or been close to losing money to IT scams has people around my age.

"Very old" != "older" (folks)

Pedantry.

There are good UI solutions to this problem... For example, a dialogue box that asks you to type "Yes I am sure I want to delete all my data, forever". We do things like this for internal tools at work, seems to go pretty well.

Bear in mind the specific case being discussed is for B2 buckets, not Backblaze personal backup. Anyone using the B2 interface directly I would hope could be viewed as technically competent. If they can distinguish between the two on their end, it would make sense to provide it as an option for B2 at least.

The best way to deal with 'are you really really sure' is something like send an email with a link you have to visit as confirmation as that breaks you mentally out of the 'keep confirming without thinking' cycle which we are all at least slightly prone to given the number of confirmation dialogues we all see these days.

GitLab makes you do something similar to delete a repo, but not as explicit with the message. I think you just have to type the repository name in a box (to confirm you read the instructions) and click the delete button.

Wasn't that response talking about Backblaze personal backup, not B2? I would assume that B2 would be targeted at more technical users.

The personal backup product and B2 aren't the same thing and weren't developed with the same principles.

Then how do those customers ever delete anything? Click every single file and choose "Delete"?

Disclaimer: I work at Backblaze.

> How do those customers ever delete anything? Click every single file?

The current recommended work around is to write a very short "life cycle rule" in the web GUI that deletes any/all files 1 day after it is uploaded and let it run for 24 hours and come back to an empty bucket. Yes, I know this is lame. https://www.backblaze.com/b2/docs/lifecycle_rules.html

Just to be clear, there are two separate product lines at Backblaze: 1) Backblaze Personal Backup which is COMPLETELY automatic and you don't need to delete anything, ever, it is all automatic, and 2) Backblaze "B2" which is a toolkit for IT people and programmers. This is only a problem for the "B2" side, and the IT people and programmers (for now) can write a script or write the "life cycle rule". But we will get this fixed, it is on the roadmap.

Thanks! I wasn't clear about the distinction between those products. Given that information, it really isn't a major issue, if maybe a bit clunky.

I don't think that comparison does make sense. B2 is much more of a pro offering.

Looking at the pricing at: https://www.backblaze.com/b2/b2-transactions-price.html

It seems that calling b2_delete_key is free. It's just not conveniently abstracted. Listing the items however if you don't already have a catalog is $4/M items

> Listing the items however if you don't already have a catalog is $4/M items

That doesn't seem correct. Each call to b2_list_keys can return up to 10 000 results, so it's $0.40/M items.

Amazon S3 does the same thing. You can make bulk requests but you still are responsible for deleting all objects before removing the bucket.

Agree it's stupid.

Here's a video on deleting a bucket with a large number objects I just watched & found informative. It basically says something like you disable versioning, expire objects after 1 day, delete deletion markers, and delete deleted deletion markers (getting a little meta there).

https://youtu.be/TPavkqp-Ymo

You can nuke a whole S3 bucket. There's a switch in the cli and a checkbox in the GUI. I think there's another option for deletion protection that disables that somewhere else

I can't find the CLI option, the docs still say that the bucket must be empty[1]. There's something available in the management console but that doesn't really help with automated deployments and testing.

[1] - https://docs.aws.amazon.com/cli/latest/reference/s3api/delet...

Edit: Found aws s3 rb --force, but this just automates the process of listing/deleting objects then deleting the bucket. When you have 7 million objects in a cloudtrail bucket, that can take days.

No, you can nuke a bucket with stuff in it. I just realize I've never done this before, but the deletion screen calls out that all the contents will go away too.

https://i.imgur.com/j1av6iE.png

That screen will first delete all the items. It just issues the api calls for you. The amazon web interface is built on the API. It can’t do anything that you can’t do via the API.

Not all of those APIs are published or available via standard libraries...particularly with newer services.

That must be a somewhat recent addition - a year or two ago it wasn't possible (and the suggestion was what was posted in another comment - set the lifecycle rules to expire all the objects in a day)

edit: actually the "don't close your browser window" warning leads me to believe that's just a client-side JavaScript solution which doesn't work with massive buckets (we had one with millions of objects)

Why would the Javascript solution be inherently unable to deal with large buckets? Do we have to assume that they're taking some incredibly naive approach and trying to load every single ID into memory at once instead of streaming them out in chunks? It seems like Amazon should be capable of hiring an engineer who knows what they are doing.

It just seems like an inherently slow process. I remember at the time there was a python script someone wrote, which used the API to delete them in 1000 object chunks, and even running that with 10 threads the delete was going to take days and days.

The problem is the duration and durability of the exercise when you have millions of objects in the bucket. It could easily take days.

At least it's the kind of problem you can come back to and restart if the process dies in the middle. You're bulk deleting data so maintaining integrity isn't a concern.

This isn't strictly true - If you use the S3 dashboard the Delete Bucket button will abstract all the individual object deletes away for you.

I seem to remember the same experience (not completely sure if it was Backblaze, though).

Good to know I wasn't stupid. Couldn't shake the feeling at the time that I was missing something.

I was able to delete everything using their bucket browser UI. did you try that?

The web UI button specifically says the bucket cannot be deleted because it has contents.

You can set a lifecycle rule for the bucket to delete all objects after a number of days. This way they wil be deleted automatically.