S3文档说明一年的S3对象持久性为99.999999999（11个9）。如果对象在'n'区域/桶上复制/复制，则对象是多少耐久的。
答案 0 :(得分：1)
问：亚马逊S3有多耐用？
Amazon S3标准版和标准版 - IA旨在提供给定年份内对象的99.999999999％耐久性。该耐久性水平对应于平均年度预期损失0.000000001％的对象。例如，如果使用Amazon S3存储10,000个对象，则平均每10,000,000年可能会丢失一个对象。此外，Amazon S3旨在维持两个设施中的并发数据丢失。
每个对象都被“幕后”复制到另外两个数据中心。每个数据中心在物理上是分开的，具有单独或冗余的设施（网络，电力等）。
如果您对11x9s的持久性不满意，可以使用跨区域复制将对象复制到不同区域的存储桶，这将再次跨三个数据中心进行复制（制作6总计副本。）
耐久性将是1-（11x9s x 11x9s），这是所有六个设施失败的可能性。如果发生这种情况，你生活中要担心的事情要比丢失数据（例如全球热核战争）更糟糕。
答案 1 :(得分：1)
这个问题让我开始疑惑......你怎么把这样的数字放在耐久性上？ S3如何提供11 9的耐用性，为什么旧的Reduced Redundancy Storage（RRS）级别的耐用性明显低得多，只有99.99％（4 9），即使它仍然存储在2个AZ中，而不是3个
答案似乎在于每个存储实体（可能是硬盘驱动器）的年度故障率（AFR）的统计几率，但鉴于商品硬盘驱动器的故障率在统计上更高 - 也许高达4％的AFR - “存储设备”可能是RAID阵列，或其他每个独立存储实体具有1％AFR的集群技术。为简单起见，我将此实体称为“存储设备”。我的意图是不声称S3使用 n 硬盘驱动器来存储对象;这几乎肯定是过于简单化了，我对S3的内部工作原理没有任何了解。
为了便于说明，我们简要假设维护良好的车队中的存储设备的AFR为1％。显然，这假设物理驱动器在达到过高的年龄之前就已从服务中移除，否则它们最终都会失败。
运行断言丢失存储设备的可能性为1/100，在给定年份失败的可能性为99％。然后，我们可以每年将设备的内容称为99％耐用。
如果我们在两个这样的设备上存储相同的数据，并且系统被设计成使得两个设备的故障不可能具有任何相关原因（例如，它们不仅不在同一个机柜中或在同一个机柜中电源，它们甚至不在同一个建筑物中），我们可以说并发故障在统计上是独立的，我们可以通过将概率相乘来确定同时丢失两个设备（导致内容丢失）的可能性：0.01 ×0.01 = 0.0001或0.01％。因此，在两个驱动器上具有相同的内容时，丢失它们的几率提高到99.99％。
我们可以将其外推到许多存储设备：
1 0.010000000000 99%
2 0.000100000000 99.99%
3 0.000001000000 99.9999%
4 0.000000010000 99.999999%
5 0.000000000100 99.99999999%
6 0.000000000001 99.9999999999%
奇怪的是，我们得到的数字与S3的已发布规格非常相似，我们知道在3个可用区域内冗余存储对象。如果我们假设“冗余”意味着每个区域中有两个存储设备，那么我们的耐用性非常接近11 9（实际上略高）。
减少冗余存储存储的对象复制的次数较少且只有2个可用区域，我们发现2个设备的统计失败率确实可以预测99.99％的持久性。
所有这一切都是为了尝试确定“持久性”对于存储对象的真正含义，并且它当然似乎指的是丢失对象的每个副本的几率。
通过扩展，将对象复制到第二个AWS区域意味着我们需要将无限小的几率相乘，这会使统计持久性增加额外的 ~11 9（22 9），因为在2个不同地区的6个可用区域中12个独立存储设备的故障应该是绝对不可修复的，并且不太可能永远不可能。
当然，问题在于，在这些小数字中，出现其他错误的可能性，与纯粹的持久性无关 - 如管理错误，恶意事件，甚至是S3中的缺陷 - 似乎通过比较变得更有可能......但跨地区的复制也可能有助于防范这些事情。对象版本控制也是帮助防止数据丢失的一个很好的功能，因为某些类型的无意错误不太可能发生。