Comment Re:Are those solid state drives? (Score 1) 22
Doesn't really give me warm and fuzzy feelings about the reliability of my backups
TL;DR: If you depend on only one strategy for your absolutely business critical backups, you are in for failure and bankruptcy.
BackBlaze is a bit shy about telling us exactly what's on the back end of their system. On SWIFT object store, the configuration specifies the number of copies of an object, typically 3 but that can be set to whatever makes sense as long as it's +1. As long as two are available, you get your stuff. If only one copy is available, then you can't download it until someone replaces one of the two drives that failed or fixes the server those drives are attached to or corrects the networking between replication server pools in the case of Geographically Separated silos. Replication daemons ensure no copies of an object are stored on the same server, let alone drive and that the quorum is maintained
Bit rot does occur. Times it does are either catastrophic events in the DC or failure to maintain the ring by failures of maintenance (not done, no parts, lack of funds...). Keep in mind all object stores are "eventual consistency" systems. You upload, you'll get an OK as soon as quorum minus 1 is met. On a three copy system when two are committed and complete, you get the kiss off. The third will complete "eventually". Usually within seconds but weeks is possible too. It is also possible to get a revision of a object that is older than the other two. Using unique naming of an object would avoid that, since you can't change an object, only download, make the change, then reupload the entire object. When depends on factors of internetworking traffic, latency, maintenance... in short, availability. Good quick read on that is Jon Johnson's "The CAP theorem". Or, if you want the real deep dive, the architecture docs on SWIFT were where I learned - maybe there's better, but I don't know. They are somewhere around on NASA's site last I knew in 2012.