Eleven nines: what a durability model does not prove
Published 2026-10-11 · updated 2026-10-15
A durability target is not a measured loss rate. Recomputing a historical 20-shard example gives about 1.06e-11 per year with a Poisson event model and 7.72e-12 with a distinct-shard binomial model. The difference is a modeling choice, not evidence that one cloud provider is safer.
- Vendor scope
- S3 Standard, not every S3 storage class
- Historical example
- 20 shards, 17 required; Backblaze's 2018 assumptions
- Our contribution
- Reproducible arithmetic and explicit model boundaries
- Not measured
- No observed loss sample or provider comparison
What the numbers mean
S3 Standard has an eleven-nines annual durability design target and spans at least three Availability Zones. One Zone-IA and Express One Zone use one zone; the same broad product name does not imply the same fault coverage. Availability is a separate property. Sources 1 and 2 identify the applicable classes.
The historical Backblaze example assumes 20 shards, any 17 sufficient, 156-hour repair periods and an effective annual rate of 0.0041 per drive. Its recovery-service credit rounds half of 0.81% to 0.41%. Those are historical modeling inputs, not a present-day measurement. Source 3 supplies the inputs; source 5 supplies the distinct-shard construction.
Our arithmetic distinguishes exactly four events, at least four events, and at least four different shards. At the baseline, adding the Poisson tail changes the annual result only about 0.029%; switching to the finite distinct-shard calculation changes it much more. For rare events, the binomial leading coefficient divided by the Poisson coefficient is (20 x 19 x 18 x 17) / 20^4 = 0.72675. Neither model is thereby validated against real loss.
Expectation is not a waiting-time guarantee. Ten million objects at a hypothetical annual marginal loss probability of 1e-11 imply 0.0001 expected losses per year, even without independence between objects. Computing the probability of any loss requires their joint behavior: with independent object-years, the probability over 10,000 years is about 63.2%, not certainty and not a promise of a loss-free interval.
Greenan, Plank and Wylie distinguish time to first loss from its magnitude. Their NOMDL metric expresses expected bytes lost per usable terabyte over a stated mission time. A long MTTDL alone does not report either loss severity or finite-horizon risk. Their small-array examples are not cloud measurements or results reproduced here.
Events are not distinct shards
Let a be a constant per-drive hazard in failures/year, h the window in hours, m = 8760/h and mu = 20a/m. The printed Poisson expression is exp(-mu) mu^4 / 4!, the probability of exactly four events. Summing from four upward includes higher event counts.
For distinct shards, p = 1 - exp(-a/m) and q = sum from k = 4 to 20 of C(20,k) p^k (1-p)^(20-k). The notebook annualizes q as 1 - (1-q)^m. This still partitions time into fixed windows: it does not track the first failure's repair clock across a boundary.
The comparison uses m = 8760/h for all three columns. The separate downloadable result also reproduces the blog's rounded m = 56 (or 28 for the doubled window), so arithmetic conventions remain visible. The fourth-power rate and third-power window scaling are rare-event approximations, not exact laws for arbitrary rates.
| Scenario | Rate / year; hours | Exactly 4 events | At least 4 events | At least 4 distinct shards |
|---|---|---|---|---|
| Historical inputs | 0.41%; 156 h | 1.0624e-11 | 1.0627e-11 | 7.7236e-12 |
| Without recovery credit | 0.81%; 156 h | 1.6161e-10 | 1.6170e-10 | 1.1754e-10 |
| Illustrative 2% rate | 2.00%; 156 h | 5.9813e-9 | 5.9898e-9 | 4.3550e-9 |
| Double window | 0.41%; 312 h | 8.4865e-11 | 8.4914e-11 | 6.1722e-11 |
Reproduce with the Python generator; inspect full-precision JSON or scenario CSV. Code uses 70-digit decimal arithmetic; extra digits are computational precision, not evidence.
Historical source figures
Source figures and our derived arithmetic are labeled separately. The four-scenario comparison above is generated from published code; the source table below preserves the historical extract with corrected scopes. Source review: 2026-10-15.
| Measure | Value | Unit | Population or scope | Source |
|---|---|---|---|---|
| S3 Standard durability design target | 99.999999999 | percent of objects per year | S3 Standard (vendor target) | Source 1 |
| Minimum Availability Zones holding an object | 3 | zones | S3 Standard; excludes One Zone classes | Source 2 |
| S3 Standard availability target | 99.99 | percent per year | S3 Standard | Source 1 |
| Annual loss probability implied by 11 nines | 0.00000000001 | probability per object per year | Derived by us: 1 minus 0.99999999999 | Source 1 |
| Expected losses a year with 10,000,000 objects | 0.0001 | objects per year | Derived by us: 10,000,000 x 0.00000000001 | Source 1 |
| Shards per object, Backblaze B2 | 20 | shards | Reed-Solomon, 2018 post | Source 3 |
| Shards needed to rebuild an object | 17 | shards | Same scheme | Source 3 |
| Missing shards exceeding the coding tolerance | 4 | distinct unavailable shards | Ideal 20/17 code, no other corruption | Source 3 |
| Drive annualized failure rate assumed | 0.81 | percent per year | Backblaze average over the trailing 60 days of the post | Source 3 |
| Effective failure rate used in the derivation | 0.41 | percent per year | Backblaze | Source 3 |
| Rebuild interval assumed | 156 | hours (6.5 days) | Backblaze | Source 3 |
| Poisson probability of exactly 4 events in one interval | 0.000000000000189 | probability per 156 hour interval | Historical event-count approximation | Source 3 |
| Intervals per year used | 56 | intervals | Backblaze | Source 3 |
| Durability Backblaze states | 11 | nines | Backblaze B2, 2018 | Source 3 |
| Printed-window Poisson approximation, recomputed | 0.0000000000106 | probability per object per year | Derived: exactly 4 events, 56 periods | Source 3 |
| Same formula with 0.81% failure rate (no recovery credit) | 0.00000000016 | probability per object per year | Derived by us | Source 3 |
| Same formula with 2% failure rate | 0.0000000060 | probability per object per year | Derived by us | Source 3 |
| Same formula with a 312 hour rebuild | 0.000000000085 | probability per object per year | Derived by us with 28 intervals a year | Source 3 |
| Expected losses for fixed 1e13 object-years | 100 | objects | Derived: exposure x 1e-11; not a waiting-time guarantee | Source 3 |
| MTTDL value cited for the Pergamum archive | 1400 | years | Greenan et al. cite it as an example of a Markov-model estimate | Source 4 |
| MTTDL for a sample 8-disk RAID4 array | 37.60 | years | Greenan Table 1: Markov-model example; not a finite-horizon loss probability | Source 4 |
Method
We reviewed AWS storage-class documentation, Backblaze's 2018 derivation and pinned notebook, and Greenan, Plank and Wylie's HotStorage 2010 position paper. Our Python standard-library generator uses 70-digit Decimal arithmetic. It reproduces the printed 56-window calculation separately from the 8760/hour-window convention, sums the Poisson tail directly, and independently evaluates the finite binomial sum. Four parameter sets are deterministic sensitivity scenarios, not a sample of observed losses. No AWS implementation is reconstructed.
Limits
All window calculations assume independent, constant-rate shard failures and independent fixed periods. They do not model overlapping repairs, losses straddling period boundaries, latent corruption, shared dependencies or operational deletion. The fractional annual exponent is a historical approximation, not an event-driven repair simulation. Extra decimal digits reduce rounding error but do not reduce model uncertainty. No empirical confidence interval, provider ranking or guarantee follows.
Questions to ask before using nines
Specify the loss event, object or byte denominator, mission time, storage class, fault domains and repair policy. Then ask whether inputs describe measured exposure, vendor assumptions or an illustration. A durability target does not replace versioned backups, restore verification or a policy for deletion and key loss.
Related: MTTDL, NOMDL, AFR versus probability, correlated failures and the source dataset.
Sources
- 01Amazon S3 FAQs, Durability and Data Protection (AWS, vendor document) · accessed 2026-10-15
- 02AWS S3 User Guide: storage classes, durability and Availability Zone scope · accessed 2026-10-15
- 03Backblaze Durability Calculates at 99.999999999% And Why It Doesn't Matter, Brian Wilson, Backblaze blog, 17 July 2018 (vendor derivation) · accessed 2026-10-15
- 04Mean time to meaningless: MTTDL, Markov models, and storage system reliability, Greenan, Plank, and Wylie, USENIX HotStorage 2010 (USENIX PDF, independent academic source) · accessed 2026-10-15
- 05Backblaze erasure-coding durability notebook, pinned revision 37f758d · accessed 2026-10-15