ralphbsz very good points. 11 nines is probably related to availability (like telco 5-nines).
No, that's a durability number. My definition is: If I store 10^11 objects for one year, the expected number of objects not being readable is less than 1 (and let's not worry about rounding, whether it is 1/2 or 1 object broken).
You will notice several interesting things here. First, durability is actually a data loss rate, not a timeless number. If I were to store the same 10^11 objects for 10 years, an expected number of failures of 10 (or 5?) would still satisfy me, since the annual loss rate remains better than the "11 nines" I wanted.
Second, the above definition depends crucially on what "readable" means. Let me give you two extreme examples, using made-up (but realistic) numbers. Normally, when I read a small object (less than 1MB), I expect the read to take 100ms, even if I am running 1000 read threads in parallel. Now something bad happens (like a fire in a data center of my cloud provider), and that read suddenly takes 200ms. Should I declare that to be a data loss event, just because I'm inpatient? Opposite example: I try the read once, and get an error (the cloud API tells me that the object is unreadable). About an hour later I get an e-mail from the provider: They noticed that I got a read error, and they apologize: one of the data centers has burned down, while the backup data center was wiped out by a hurricane. But not to worry, they store off-line backups on a third continent, and will retrieve my data. Unfortunately, it will take about a week to get the data out of the dungeon, so they suggest that I retry the read in two weeks. In the meantime, they are crediting my monthly bill and are very sorry.
So which of the two examples is a data loss event? Is being 100ms late already a disaster, or can I expect to wait a week or two? Well, that depends on the SLA or service level agreement. Typical SLOs (objective, part of the agreement) might be "after a failed read attempt, retry at least two times", and "while we strive to serve all requests quickly, and commit to an average read time of about 100ms, about 1% of all reads may take up to a second, and 10^-5 may take up to a minute."
Finally, all this has to be embedded into the legal and contractual framework. Say for example I'm a large customer of one of the cloud services, and I store a trillion (10^12) objects, and my annual storage bill is $100M. At that level, the 11 nines begins to be meaningful: I'm expecting roughly 10 of my objects per year to be lost. So now what happens if things go wrong? For example, this year my provider does very well, and only loses 3 objects. Do I expect to get a tenth of a penny back on my next bill? Next year, they do TERRIBLY, and lose 17. Is that a contract violation? Do I get all my $100M back? Say we have the problem described above (fire + hurricane), and the SLA described above (no reads take longer than 1 minute). So when the provider sends the e-mail saying "it will take a week or two to get your data back", can or should they demand that I throw an extra quarter into the machine for that service? (For non-US people: A quarter is $0.25, and the largest coin commonly used on vending machines.)
"active account": I only use this for backups so not used every day, just maybe once a week to push data. What happens on the I need to recover data event?
What I meant is the following: In order to read my data back, I have to be a customer of the cloud service, in good standing, with my bills paid. If I stop paying my Azure bills for 3 years, I should not expect to get ANY of my data back, and the "11 nines" are completely irrelevant. This seems uncontroversial. So how do I make sure I actually pay my bills? Credit cards expire.
Where it gets controversial: Say I'm using Amazon S3 to store my data, and I pay my monthly AWS bill on time. One day I order a new pink pillow for my sofa from Amazon, and when it arrives, I find that it is extremely ugly. I write a bad review of it. I mean REALLY bad, using 4-letter words to describe the color. Amazon gets upset, and cancels all my accounts. Now I can not get my data back. Is this a real risk? Obviously, this is a constructed example, and I'm not suggesting at all that Amazon would do such a thing (and yes, I'm an AWS S3 customer and I also order stuff from Amazon all the time, they have been a pleasure to deal with). But seriously, contractual and legal disputes are a significant fraction of data loss events, and they are not counted in the "11 nines" we discussed above.
At one point in time, tapes and CD-ROM were considered the gold standard. But now not so much, so I think it becomes "will I be able to read this media in the future".
That depends on your definition of "future". It brings up a lot of complex question. My old colleague Raymond Lorie (may he rest in peace) worked intensely on the theoretical CS side of: how do we define data formats such that we can still decode them in the far future. If the Mycenaeans who wrote Linear A 3500 years ago had only listened to him, their clay tablets would be decodable today! The answer is to use some redundancy, and write in self-describing formats. I actually worked on the hardware side of this problem, and got a patent for using glass as a computer tape material that remains readable for 500-1000 years.
In practice, none of these ideas have really gone anywhere in commercial use. It's just cheaper and easier to recopy the data regularly, for example every 3 or 10 years. Each time, you can use up-to-date formats and media. This also addresses the question Cracauer asked earlier: why would you use a closed-source backup application that writes in an unknown format? Because the problem of not being able to read the data does not really occur in production settings, as data gets copied (and intentionally deleted after retention periods end) regularly. For amateurs and historic artifacts, it's harder. A few years ago, I spent a weekend helping to decode a backup tape of the source code of System R (the first relational database), written 50 years ago. It was doable but hard; I think the files are now stored at (and perhaps even available from) the Computer History Museum.
