3 ms·

Thanks for your detailed answer! > In the case of the Zip file download, we chose the format of zip because both Mac and PC (the most common desktops) natively

Thanks for your detailed answer! > In the case of the Zip file download, we chose the format of zip because both Mac and PC (the most common desktops) natively understand it with no additional software needed. In other words, if you just lost your computer, go to ANY COMPUTER ANYWHERE and you can fetch your files with a web browser. Zip preserves the file hierarchy and the last modified time, so it's "pretty good". Security issues aside, from a space and time perspective, that's much less convenient for both you and me: it takes time and space for you to prepare the zip file, and space and time for me to save it and extract it. It would be better to install a simple client and restore the files directly into a directory. In the case of a few files, it doesn't matter much, but in the case of gigs of files, it definitely becomes a problem. Is there any chance of you implementing a more CrashPlan-like restore option in the future? > Longer Answer: To clarify, Backblaze produces four different products/modes for different customers with different needs and requirements. We want customers to choose what is appropriate for them. One size does not fit all: I wish this explanation were on the Backblaze web site, because this makes it very clear. :) Is there any chance of implementing a hybrid of #2 and #4, a client-based, zero-knowledge option? i.e. basically, CrashPlan's client in the private-key mode. If Backblaze were to implement this, and add a Linux client, I'd seriously consider switching. Thanks for your time.

brianwski 9y ago
> it takes time and space for you to prepare the zip file, > and space and time for me to save it and extract it One advantage is that for millions of small files, batching them together into one monolithic ZIP file allows for faster downloading. As opposed to a round trip to fetch each file. But there could be a happy medium where we batch 1,000 encrypted files to download to your computer then split them up, decrypt them, and cleanup any temporary files before fetching the next 1,000 encrypted files, etc. > Is there any chance of implementing a hybrid of #2 and #4, > a client-based, zero-knowledge option? Yeah, we get asked for a "client restore option" quite a bit (see other comments in this thread also). Realistically I don't see it happening in the next 6 months, but eventually we really should get it done.
- explainplease 9y ago
  > One advantage is that for millions of small files, batching them together into one monolithic ZIP file allows for faster downloading. As opposed to a round trip to fetch each file. But there could be a happy medium where we batch 1,000 encrypted files to download to your computer then split them up, decrypt them, and cleanup any temporary files before fetching the next 1,000 encrypted files, etc. Well, any such software that didn't have pipelining would be poorly designed. ;) Compare to software like rsync, Unison, etc, which transfer large numbers of small files quickly. Seems like a good solution would be to build on librsync.

brianwski 9y ago

> it takes time and space for you to prepare the zip file, > and space and time for me to save it and extract it One advantage is that for millions of small files, batching them together into one monolithic ZIP file allows for faster downloading. As opposed to a round trip to fetch each file. But there could be a happy medium where we batch 1,000 encrypted files to download to your computer then split them up, decrypt them, and cleanup any temporary files before fetching the next 1,000 encrypted files, etc. > Is there any chance of implementing a hybrid of #2 and #4, > a client-based, zero-knowledge option? Yeah, we get asked for a "client restore option" quite a bit (see other comments in this thread also). Realistically I don't see it happening in the next 6 months, but eventually we really should get it done.

explainplease 9y ago
> One advantage is that for millions of small files, batching them together into one monolithic ZIP file allows for faster downloading. As opposed to a round trip to fetch each file. But there could be a happy medium where we batch 1,000 encrypted files to download to your computer then split them up, decrypt them, and cleanup any temporary files before fetching the next 1,000 encrypted files, etc. Well, any such software that didn't have pipelining would be poorly designed. ;) Compare to software like rsync, Unison, etc, which transfer large numbers of small files quickly. Seems like a good solution would be to build on librsync.