Glossary
Data durability
Data durability is the probability that stored data remains intact and retrievable over a stated period. It describes how many independent failures a storage system can absorb before data is lost, and is normally quoted as an annual figure.
Durability is a property of a configuration rather than of a medium. The same drives yield very different durability figures depending on how many copies or parity fragments exist, how those are distributed across independent failure domains, and how quickly the system restores redundancy after a failure.
Durability and availability distinguished
Durability is the probability that data still exists. Availability is the probability that it can be reached at a given moment. The two are quoted separately because they are produced by different mechanisms and fail in different ways.
A network partition, a failed load balancer or a planned upgrade can make a system unavailable while every byte remains intact, and availability returns when the cause is cleared. A system can also report success for a write that was never made durable, which costs durability while availability appears unaffected. Redundancy raises both, but availability additionally depends on the paths, services and identity systems in front of the data, none of which are part of a durability figure.
How durability figures are expressed
Durability is written as a percentage with a count of leading nines, describing the expected proportion of stored items that survive one year.
| Stated durability | Annual probability of losing a given object | Expected losses per year in a collection of 10 million |
|---|---|---|
| 99.9 percent, 3 nines | 1 in 1,000 | 10,000 |
| 99.9999 percent, 6 nines | 1 in 1,000,000 | 10 |
| 99.9999999 percent, 9 nines | 1 in 1,000,000,000 | 0.01 |
| Eleven nines | 1 in 1011 | 0.0001, or one object every 10,000 years |
The unit the figure applies to matters as much as the number of nines. A probability quoted per object and the same probability quoted per volume or per byte describe different things, and a collection of a billion small objects and a collection of a thousand large ones draw very different expected losses from the same per-object figure.
The failure model behind the arithmetic
A durability figure is the output of a model, and the model rests on three inputs: how often a device fails, how many devices must fail before data is unrecoverable, and how long the system remains short of redundancy while it repairs.
Device failure is expressed as an annualized failure rate. A population with a 1 percent annualized failure rate loses one drive in a hundred over a year. Repair time converts that into an exposure window: four hours is 4 divided by 8,760, or 0.00046 of a year, so the probability that a particular second drive fails inside that window is approximately 0.01 multiplied by 0.00046, about 4.6 in a million. Durability figures are products of chains of terms of this kind, which is why they reach magnitudes that are difficult to test directly.
The chain assumes failures are independent. Drives from one manufacturing batch, in one enclosure, on one power feed or running one firmware version do not fail independently, and a published figure holds only to the extent that the assumption does. Distributing copies or fragments across separate failure domains, meaning separate servers, racks, power feeds or sites, is what makes the assumption closer to true.
Replication and erasure coding
Two schemes provide the redundancy the model counts. Replication keeps whole copies, so n copies survive the loss of n minus 1. Erasure coding divides data into k fragments and computes m additional fragments, so any k of the k plus m fragments reconstruct the original and the scheme survives the loss of m.
| Scheme | Fragments stored | Simultaneous losses tolerated | Capacity overhead |
|---|---|---|---|
| 2 copies | 2 | 1 | 2.00 times |
| 3 copies | 3 | 2 | 3.00 times |
| 4 plus 2 erasure coding | 6 | 2 | 1.50 times |
| 9 plus 3 erasure coding | 12 | 3 | 1.33 times |
| 17 plus 3 erasure coding | 20 | 3 | 1.18 times |
Wider schemes carry less overhead for the same number of tolerated failures, and they spread each stored item over more devices, so every write involves more devices and every repair reads from more of them. The trade is that a scheme spanning 20 devices requires at least 20 independent devices to place them on, which sets a floor on the size of the system it can be used in.
Rebuild time as the dominant variable
Of the three inputs to the model, repair time is the one a system's design most directly determines, and it enters the arithmetic as the length of the exposure window.
Where a single device is the bottleneck, the time to restore redundancy is set by its capacity and the rate at which it can be written. A 20 TB drive written at 200 MB per second takes 20 times 1012 divided by 200 times 106 seconds, which is 100,000 seconds, or approximately 27.8 hours. A system that instead spreads the affected data across many devices restores redundancy in a fraction of that time, because many devices contribute in parallel rather than one absorbing the whole write.
Two further factors shorten the window. Rebuilding only the data that was actually written, rather than the full capacity of a failed device, makes repair time proportional to how full the device was. And repair traffic shares the devices with production requests, so the rate a system can sustain during rebuild is lower than its idle maximum, which is where rebuild time and storage latency meet.
Silent corruption and scrubbing
The model above counts devices that fail visibly. Media also degrade quietly: a sector returns data that differs from what was written, and the device reports the read as successful. Undetected, such a block is copied into new replicas and folded into parity recalculations, and it can outlive the original data.
Detection requires a checksum computed when data is written and verified when it is read, held separately from the data itself. Because rarely read data can sit unverified for years, systems also scrub in the background, reading stored data on a cycle and reconciling it against the checksums, so that corruption is found and repaired from redundancy while redundancy still exists.
What durability figures do not cover
A durability figure describes a storage system preserving what it was given. Several classes of loss fall outside it entirely.
Deletion by an authorized user or an application acting with valid credentials is a correctly executed instruction, and the system carries it out across every copy. Encryption by ransomware holding valid credentials is likewise a sequence of legitimate writes. Corruption produced by an application is stored faithfully. Loss of a whole site removes every copy held there, so site loss is covered only by a scheme whose failure domains span sites. In each case the storage system did exactly what a high durability figure promises, and the data an organization wanted back is gone. Versioning, retention controls and separate backup copies address these cases; the durability figure does not.
Durability at Scality
Scality RING protects data with erasure coding, and erasure coding schemes can be defined per storage class, so classes of data within one system can carry different overheads and tolerate different numbers of failures rather than a single scheme applying to everything.
On the repair side, RING writes the affected data across the remaining drives in the server that held the failed drive, and rebuilds only the data that was written rather than the full capacity of the device. A partly filled drive therefore returns to full redundancy in proportionally less time, which shortens the exposure window that the durability arithmetic above depends on.