Erasure coding and replication both help storage survive hardware failures, but they consume capacity differently. Replication keeps complete copies of data. Erasure coding divides data into fragments and adds parity, the information needed to reconstruct missing fragments. For a large object store, that difference can substantially reduce the amount of disk capacity required.
The harder question is what happens after a failure. Can applications still read their data? How much work must the surviving hardware do to restore protection? A capacity comparison becomes useful when it answers those questions alongside the storage calculation.
Consider a team planning to retain 1 PB of object data. We will use that same dataset to compare three complete copies with an illustrative 8+4 erasure coding policy, then follow what happens when hardware fails. These are planning examples, not measured performance results or a recommended configuration for every deployment.
With three-way data replication, the calculation is straightforward: 1 PB of data occupies 3 PB across three complete copies. One copy contains the original amount of data; the other two provide redundancy. That is 200% protection overhead, meaning two additional petabytes beyond the original one.
An 8+4 Reed–Solomon erasure coding policy divides each protected group of data into eight equal data fragments and calculates four parity fragments. Together, the twelve fragments occupy one and a half times the original data size. The same 1 PB therefore occupies 1.5 PB, including protection.
| For 1 PB of retained data | Three-way replication | 8+4 erasure coding |
|---|---|---|
| What is stored | Three complete copies | Eight data fragments plus four parity fragments per group |
| Space occupied, including protection | 3 PB | 1.5 PB |
| Protection overhead | 200% | 50% |
| Recoverability limit for each protected group | At least one complete copy survives | Any eight of the twelve fragments survive |
The erasure-coded example occupies half as much space as the replicated example. That is a capacity result, not proof that the two designs deliver identical availability or recovery performance. Those depend on where the copies or fragments reside and how the system handles failures.
You can calculate other erasure coding layouts by dividing the total fragment count by the data fragment count. For 8+4, that is twelve divided by eight, giving a capacity multiplier of 1.5. Apply the multiplier to the data you actually intend to retain, including retained versions where applicable.
Neither figure in the table is a complete hardware sizing recommendation. Both exclude metadata, implementation overhead, growth and free space reserved for operations. Data reduction would also change the result, but this example assumes none.
Free capacity has a direct role in recovery. When a drive fails, a distributed system may rebuild its contents onto healthy drives before someone installs a replacement. Those destinations need enough room, in locations allowed by the protection policy, to accept the repaired data.
Ask for a capacity plan that shows the protected dataset, operational reserve and expected growth separately. A system that fits the data only when every drive is healthy has not demonstrated that it can restore protection after losing capacity.
A failed drive does not necessarily mean an application outage. The system may continue serving requests from surviving copies or fragments while repairing the missing data in the background. The application can be working even though its data has less protection than intended.
That creates two separate measures: whether the data remains accessible, and how long it takes to restore the full protection policy. The latter period matters because another failure can occur while the first repair is still running.
With three-way replication, losing one copy leaves two. The storage system reads a surviving copy and writes a replacement to an eligible destination. It does not need parity reconstruction to recreate the missing bytes.
For illustration, if a failed drive held 10 TB of replica data, recreating that lost copy entails roughly 10 TB of payload reads and 10 TB of payload writes, before implementation overhead. This describes the repair work, not the time it takes. Source drives, destination drives and network links still have to carry that traffic.
Replication also does not imply that one surviving drive handles the entire rebuild. In a distributed object store, different objects can have surviving copies on different drives, allowing repair work to run in parallel. Placement and scheduling determine how widely the load spreads.
For the 8+4 example, losing one fragment leaves eleven. The original data remains reconstructable from any eight surviving fragments. To replace the missing fragment, the system reads surviving fragments, calculates the missing content and writes the replacement.
The amount written is therefore only part of the recovery workload. In a straightforward Reed–Solomon repair, rebuilding one fragment can require reading eight surviving fragments of the same size. Repair optimizations, caching and the pattern of missing fragments can change the actual traffic, so this is an explanation of the mechanism rather than a bandwidth forecast.
That additional work is one cost of erasure coding’s capacity efficiency. However, it does not establish that every erasure-coded system rebuilds more slowly than every replicated system. A design with many available repair sources and destinations can behave very differently from one constrained by a small group of busy drives.
An 8+4 policy describes fragment tolerance within each protected group. Translating it into server, rack or site tolerance requires knowing where those fragments are placed. A failure domain is a set of components that can become unavailable together, such as the drives inside one server.
Suppose the twelve fragments are spread across six servers, with two fragments on each. Losing one server removes two fragments. Losing two servers removes four, leaving exactly the eight needed to reconstruct the data. A third server loss removes too many.
Now suppose three of those servers share a rack. A rack outage could remove six fragments at once, exceeding the protection limit even though the policy still says 8+4. The arithmetic has not changed; the placement has changed what a single incident can take away.
Replication has the same dependency on placement. Three copies on different drives inside one server do not survive the loss of that server. To assess either method, ask how many copies or fragments of the same protected data a particular failure can remove.
Recoverability also differs from permission to accept new writes. A system may deliberately stop writes before it reaches the minimum needed to read existing data. Confirm the platform’s read and write behavior at each failure level instead of treating fragment tolerance as an availability guarantee.
It is easy to assume that erasure coding requires decoding every object whenever it is read. That is not how all implementations work. With systematic coding, the original data fragments remain directly readable; reconstruction is needed when required data fragments are unavailable.
Scality RING provides a concrete example. Its documented erasure coding design preserves directly readable data fragments, avoiding parity decoding during normal reads when those fragments are available. If a required data fragment is missing, the read path must reconstruct it using surviving fragments.
This is why a benchmark taken only with healthy hardware cannot answer the recovery question. During a failure, some application reads may need reconstruction while background repairs are also using the cluster. CPU, drives and network links must support both activities.
The workload matters too. A repository serving large sequential object reads places different demands on storage from one handling frequent small requests. Measure the object sizes, request patterns and concurrency your applications generate, including periods when backups, restores or ingestion overlap.
A useful evaluation starts with an application requirement. For a backup repository, that might be finishing the backup window while sustaining a specified restore rate. For an archive, it might be keeping retrieval response times within an agreed limit during hardware repair.
Run the evaluation on representative hardware, with realistic occupancy and data distribution. An almost-empty cluster gives a misleading picture of destination space and competing load. Establish a healthy baseline, then use an agreed failure procedure in a test environment while the application workload continues.
Record these four outcomes together:
Recovery throttling makes the relationship between these results especially important. Reducing repair activity may protect application performance but extend the period of reduced redundancy. Increasing it may restore protection sooner while slowing production work. Evaluate the settings you would actually operate.
Keep storage repair separate from application recovery in the report. A cluster may restore its redundancy successfully yet fail to deliver backup data fast enough for an urgent restore. For a backup workload, run a restore during the rebuild and measure the result.
A mixed policy can make sense when different data types have different needs. Small objects may benefit from replication, while larger objects make the capacity savings of erasure coding more significant. The decision can happen within the storage platform rather than forcing every application onto a separate system.
Scality RING supports both replication and erasure coding. Its architecture documentation describes mixed policies that replicate smaller objects and erasure-code larger ones. It also describes distributed self-healing, with missing data rebuilt onto available storage resources.
For sizing, this means the overall capacity multiplier depends on the mix. Applying an erasure coding multiplier to the entire dataset can understate requirements if a meaningful share remains replicated. Ask for the capacity estimate to reflect the proposed policy and the actual object-size distribution.
Hardware protection also needs to be distinguished from retaining a recoverable history. Neither extra copies nor parity alone prevents an authorized deletion or preserves an earlier, correct application state. Immutability, version retention and independent backups address those requirements separately.
For the illustrative 1 PB dataset, the capacity case is clear: 8+4 erasure coding occupies 1.5 PB compared with 3 PB for three complete copies. For a capacity-heavy repository, that makes erasure coding a strong candidate to evaluate. The next step is to validate placement and performance under failure.
Replication remains worth evaluating where small-request behavior, latency or deployment size makes it a better fit. A mixed policy may satisfy those needs without applying the capacity cost of complete copies to every byte. These choices should follow measured workload behavior and supported configurations.
Before accepting either design, require a capacity estimate with explicit reserves, a placement map showing the failures it tolerates, and a recovery test run alongside the application. Together, those show whether the system can store the data, keep serving it and rebuild its protection within an acceptable time.