Hacker News Reader

Comment by gt_ | Hacker News Reader

It's pretty clear in the comments here that all efforts other than solving the 30 day file retention limit are going to be a waste of time until you address this. It simply reduces the utility of the product to the point that you need yet another product that will almost inherently render yor product unnecessary.

Until you address this, I can't reason investing time, processor performance, or the tiny monthly payment.

Complete backup plans are taken seriously by myself and other HN users and when one tries to put one together and include Backblaze, it just doesn't add up.

Maybe you could make a blog post that addresses your recommendations head on. I remain open!

View on HN

> all efforts other than solving the 30 day file retention limit

Trust me, that message has come through loud and clear! :-) We are going to do some analysis to see if we can afford it, but we'll need at least a week or two to figure that out.

With the prevalence of crypto ransom ware ... I'd really like more than 30 days.

Speaking of which -- possibly simple feature request -- when a files' entropy suddenly goes high from low, alert the user and keep the files longer.

If you find that significantly expanding the retention limit doesn't fit within the current pricing structure (as I expect it wouldn't given how competitively priced Backblaze is), consider offering it as an add-on feature, as Dropbox does with Extended Version History (+$40/yr for 1-year retention of deleted files).

I think at a high level users might be OK with paying for their actual stored file size.

A way of improving the storage size might be to allow the user to white-list (with some defaults) folders more likely to have 'third party' files (E.G. C:\\Windows, C:\\Program*, /usr/) either excluded if they're on a list of common files or de-duplicated with a public list of common files (and check-sums). It would be useful to add-on programs and scripts if that list were public, and if a way of cloning those files in to a discounted pool were possible by 'uploading' them again (to ensure the customer actually /has/ that file and thus presumably the right to restore it).

Another feature (which didn't exist the last time I checked) SHOULD be to have /append only/ accounts.

It should be a /more privileged/ instruction to delete / replace / modify already stored files. This could prevent a backup service on a compromised system from removing remote backups. (Assuming the administrative information was kept secure using other means.)

Ideally I'd like to be able to manually assign privileges to sub-accounts.

    * Modify: resume uploads older than 24 hours
    * Modify: remove/delete
    * Modify: change storage (filestream/parameters/metadata etc).
    * Append: create new buckets
    * Append: add a new file to a bucket
    * Append: add a new /version/ of a file in a bucket.
    * Append: add metadata
    * Read: all list operations
    * Read: all download operations

Note: Since the main way of racking up money on a B2 account is downloads and since compromised clients could be used to engage in a DDoS attack (by compromised legitimate customer accounts) //read// operations are actually more sensitive than might be initially guessed.

A simplified customer UI might bundle those operations together, but some advanced way of providing finely grained privileges should be created.

Edit: Fixing formatting.

Why not allow for additional retention as a paid add-on to the existing service? I can understand why Unlimited storage combined with Unlimited retention don't work well with a fixed monthly pricing model. But couldn't you keep the Unlimited storage and marry it to a per-GB cost structure for retained versions beyond 30-days? Then it would be up to advanced users to opt-in to this paid extra so that they can take advantage as they see fit (similar to Dropbox and Extended File History). Ideally all this would fit into the standard service... but if CrashPlan couldn't make that work economically then perhaps a different approach would be best?

Reply on news.ycombinator.com