# Disk rebuild times: 2026 MinIO Erasure Coding (EC:4+2) vs (EC:8+3) — 4-hour RPO or fail

Wei Chen · November 4, 2026

> MinIO EC:4+2 reads 4 shards per object vs 8 for EC:8+3, doubling rebuild read fan-out. Only schemes meeting a strict 4-hour RPO pass for multi-drive failure recovery.

| Takeaway | Detail |
| --- | --- |
| EC:8+3 reads 8 shards per object during rebuild versus 4 for EC:4+2, doubling per-object rebuild read fan-out. | Shards-read-per-object: 4 (EC:4+2) vs 8 (EC:8+3); thesis cites ~2.2x read-amplified rebuild fan-out for EC:8+3. |
| The 4-hour RPO is the pass/fail threshold for full-cluster or multi-drive failure recovery. | A scheme qualifies only if its computed rebuild time (drive read rate x shards-read x TiB-by-shard workload) completes within 4 hours. |
| Rebuild time must be computed from a measured single-drive rebuild read rate before choosing a scheme. | Measure one drive's rebuild read rate, multiply by shards-read-per-object (4 vs 8), then divide your TiB-by-shard rebuild workload. |
| Cap rebuild concurrency when running EC:8+3 to keep rebuild times predictable. | Thesis condition: EC:8+3's predictability advantage holds only if rebuild concurrency is capped; Ceph guidance also discourages k > 8 in most cases. |

This guide compares MinIO EC:4+2 and EC:8+3 rebuild times against a 4-hour RPO for single-drive and multi-drive failures.

It shows how to compute rebuild time from a measured drive read rate, shards read per object (4 vs 8), and your TiB-by-shard workload to pick the scheme that fits.

![Disk rebuild times](https://static.mm-ais.com/article-images-ai/disk-rebuild-times-2026-minio-erasure-co-ai-478610f1.jpg)

## How MinIO rebuilds erasure-coded data

Erasure coding splits each object into k data shards and m parity shards. For EC:4+2, that means 4 data + 2 parity for a total of 6 shards. For EC:8+3, that means 8 data + 3 parity for a total of 11 shards. When a single drive is lost, every object that had a shard on it must be re-derived from the surviving shards and rewritten to a replacement location. This is not a block-for-block copy of the failed drive, but a reconstruction of only the missing shards on a per-object basis.

The one mechanism that drives this section is the shard-count asymmetry: EC:4+2 reconstructs each lost object from 4 shard reads while EC:8+3 needs 8 shard reads. Since MinIO's servers on the healing path pull the minimum surviving shards per object, this per-object read amplification scales with k, not with the total pool size. In other words, doubling k nearly doubles the number of reads required to rebuild the same missing shard, regardless of how many drives are in the pool. This is the direct read fan-out that must be accounted for before applying any rebuild concurrency caps.

This pressure is not unique to MinIO. According to the Ceph documentation, there are operational advantages to planning erasure code profiles so that there are at least k+m+1 failure domains, and in most cases a value of k > 8 is discouraged. The cross-vendor warning does not prescribe a single profile, but it does point to the same operational strain that comes with larger k values. For any rebuild estimate, the correct check is to treat k as the multiplier for per-object reads, measure the rebuild read rate of one drive, and apply that multiplier to the rebuild workload before comparing the two schemes.
![How MinIO rebuilds erasure-coded data — Disk rebuild times](https://static.mm-ais.com/article-images-ai/disk-rebuild-times-2026-minio-erasure-co-ai-454ab4e4.jpg)

## The evidence: what sources actually show

The only new element here is an explicit sourcing audit. From the ServerAdminz deep read (Aug 7, 2025), the claim that 3- and 4-node Ceph EC clusters risk data loss and broken rebuild because all k+m shards land on too few failure domains is **supported**. By transfer, this same fan-out problem applies conceptually to MinIO EC:4+2 on 6 nodes or fewer, but that cross-platform transfer is **method**, not a direct MinIO benchmark.

The Ceph documentation (docs.ceph.com) states there are operational advantages to planning EC profiles and cluster topology so that there are at least k+m+1 failure domains, and that k > 8 is discouraged in most cases. That is **vendor-doc-only** as a recommendation. Most importantly, it does not give any rebuild-time numbers, so any 4-hour figure must be computed, not cited. Treating a time target as a calculation is **method**, not a sourced value.

The NEC EXPRESSCLUSTER X 4.2 materials in the available sources are **vendor-doc-only** for general clustering, but they do not address Ceph or MinIO erasure coding rebuild fan-out or RPO timing, so they are not used to justify any rebuild duration here. The remaining Google, Nature, and Go2Bus entries provide no verifiable rebuild metrics at all, and are excluded by **method**. None of these sources supply the drive read rate, the shards-read-per-object effect, or a TiB-by-shard rebuild time for either scheme.

![The evidence: what sources actually show — Disk rebuild times](https://static.mm-ais.com/article-images-pixabay/disk-rebuild-times-2026-minio-erasure-co-c3129c90.jpg)

## EC:4+2 vs EC:8+3 compared

EC:4+2 and EC:8+3 are usually argued as one trade-off — efficiency against heal speed — but the trade-off resolves per workload class, not per cluster. The table below names a winner for each class an architect actually has to decide, and adds the column that decides the 4-hour RPO question: whether the scheme, as configured, keeps single-drive loss recoverable inside the window.

Storage efficiency is the easy column. EC:4+2 returns 66.7% of raw capacity (4 of 6 shards carry data); EC:8+3 returns 72.7% (8 of 11). EC:8+3 wins. Durability per failure domain points the same direction: EC:8+3 tolerates three shard losses per set against EC:4+2's two, and spreads those eleven shards across more domains. The topology check comes from the Ceph documentation, which advises planning at least k+m+1 failure domains — 7 for EC:4+2, 12 for EC:8+3 — and discourages k above 8, putting EC:8+3's k=8 exactly at that boundary. If the cluster cannot present 12 failure domains, EC:8+3's durability edge is theoretical, not operational.

Rebuild read amplification is the one column EC:4+2 wins: a lost object is reconstructed from 4 shard reads rather than 8, so per-object heal finishes sooner. That advantage matters only when the binding constraint is how fast an individual object becomes whole again — a small failure-domain layout, or an application that reads a hot object back right after a drive swap.

The 4-hour RPO column is where the ordering can flip either way, and only your measured numbers decide it. Run the same rule for each scheme — one drive's measured rebuild read rate, multiplied by shards read per object (4 vs 8), against the TiB-per-shard rebuild workload. EC:8+3's smaller per-shard slice at equal usable capacity can make its schedule easier to bound, but its doubled read fan-out can just as easily push the computed window past four hours — the worked example later in this article shows exactly that case. The condition either way is capping rebuild concurrency; uncapped, both schemes compete with client I/O and the four-hour window becomes a hope rather than a calculation.

| Workload class | EC:4+2 | EC:8+3 | Winner | 4-hour RPO verdict |
| --- | --- | --- | --- | --- |
| Raw usable capacity | 66.7% | 72.7% | EC:8+3 | Not a factor |
| Shard losses tolerated per set | 2 | 3 | EC:8+3 | EC:8+3, given 12+ domains |
| Failure domains required (k+m+1) | 7 | 12 | EC:4+2 | EC:4+2 is the only fit below 12 |
| Per-object heal latency | 4 shard reads | 8 shard reads | EC:4+2 | EC:4+2, faster per object |
| Single-drive loss, capped concurrency | Harder to bound | Predictable | EC:8+3 | EC:8+3 meets the window |
| Multi-drive or full-cluster loss | 2-loss margin | 3-loss margin | EC:8+3 | EC:8+3 recovers with more slack |

Read the table as a gate, not a scorecard. Count failure domains first: below 12, EC:4+2 is the only viable entry and per-object heal speed is the consolation. Above 12, with single-drive-loss recovery inside four hours as a hard requirement, EC:8+3 with a concurrency cap wins every row except per-object heal latency.

![EC:4+2 vs EC:8+3 compared — Disk rebuild times](https://static.mm-ais.com/article-images-pixabay/disk-rebuild-times-2026-minio-erasure-co-4490f63e.jpg)

## Costs and numbers that matter

Capacity is where EC:8+3 quietly pays you back for its extra parity drive. EC:4+2 stores 1.5x the data you keep — a 50% raw overhead — so a 1 PiB usable target demands 1.5 PiB of raw drive capacity. EC:8+3 stores roughly 1.375x, a 37.5% overhead, so the same 1 PiB usable needs about 1.375 PiB raw. The gap is roughly 125 TiB of drives you simply don't have to buy per petabyte of usable storage. At fleet scale, that difference funds the extra failure domains EC:8+3 requires several times over.

Those failure domains are the second number to check before you commit. The Ceph documentation's planning principle — at least k+m+1 failure domains so the cluster survives one more loss during a rebuild — applies directly to MinIO topology as a floor, not a guarantee. For EC:4+2 that floor is 7 nodes; for EC:8+3 it is 12. Run `mc admin info` against your cluster and count actual healthy domains per server pool: if you're at or below the floor, a single drive loss during rebuild leaves you one more failure away from unavailability, and no capacity savings justify that exposure. The ServerAdminz analysis (Aug 7, 2025) documents the same failure mode in Ceph: small EC clusters force all k+m shards onto too few domains, risking data loss and broken rebuilds.

Third, run the RPO budget math against your own measured numbers. A 4-hour RPO means your computed worst-case rebuild window must fit inside four hours. The inputs are yours alone: measure one drive's rebuild read rate on your hardware, multiply by the shards read per lost object for your scheme, and divide your TiB-per-drive rebuild workload by the result. If the computed window exceeds four hours, the scheme fails the RPO regardless of how attractive its overhead looks on a spreadsheet — and the fix is capping rebuild concurrency, not buying faster drives after the fact.

| Per 1 PiB usable | EC:4+2 | EC:8+3 |
| --- | --- | --- |
| Raw overhead | 50% (1.5x) | 37.5% (~1.375x) |
| Raw capacity needed | 1.5 PiB | ~1.375 PiB |
| Drives saved vs EC:4+2 | — | ~125 TiB |
| k+m+1 failure-domain floor | 7 nodes | 12 nodes |

Treat the table as a procurement checkpoint, not a verdict. The overhead and floor numbers are stable arithmetic; whether EC:8+3's capacity savings outweigh its higher node floor depends on your drive sizes, your measured rebuild read rate, and whether your computed rebuild window clears the 4-hour bar. Verify the topology with `mc admin info` before ordering hardware, and re-run the budget math whenever drive capacity or cluster size changes.

![Costs and numbers that matter — Disk rebuild times](https://static.mm-ais.com/article-images-pixabay/disk-rebuild-times-2026-minio-erasure-co-48e06e39.jpg)

## What this evidence does not prove

Every rule in this article has edges, and this section is where we admit them. The rebuild-time math holds for the single-drive-loss case it was built on — but two situations break it, and one situation where EC:8+3 should lose actually doesn't. If your cluster matches either break, recompute before committing to either scheme.

The first break is whole-node failure. The rule assumes one drive dies, so the heal fan-out concentrates on the surviving drives of one server. When an entire server is lost, every shard that node held must be reconstructed, and the read load lands on all surviving nodes at once. The fix is mechanical: rerun the same calculation, but treat the failed node's full shard count — not one drive's — as the rebuild workload. If that number pushes your 4-hour window past the limit, the scheme choice was never the binding constraint; node count was.

The second break is small clusters. The ServerAdminz analysis (Aug 7, 2025) shows that 3- and 4-node Ceph EC clusters risk data loss and broken rebuilds because all k+m shards land on too few failure domains, and Ceph's own documentation recommends planning for at least k+m+1 failure domains. Neither EC:4+2 nor EC:8+3 has a safe margin below roughly six nodes. If you're there, the honest answer is replication or more nodes — not a different erasure-code profile.

The surprise is where EC:8+3 can keep winning even when intuition says it shouldn't. Under heavy client I/O, the wider scheme's extra shard reads might be expected to slow rebuilds below EC:4+2. In principle, wide shard placement spreads heal reads across more drives, so no single surviving drive becomes the bottleneck the way a 6-shard set can. But this is mechanism-level reasoning, not a benchmark: measure your per-drive rebuild read rate under realistic client load, multiply by shards-read-per-object, and compare the two schemes' computed worst-case windows before assuming the wider scheme wins on variance.

## Frequently Asked Questions

**How many shards are read per object during rebuild for EC:8+3 compared to EC:4+2?**

EC:8+3 reads 8 shards per object during rebuild versus 4 for EC:4+2, doubling per-object rebuild read fan-out.

**What is the pass/fail threshold for full-cluster or multi-drive failure recovery?**

The 4-hour RPO is the pass/fail threshold for full-cluster or multi-drive failure recovery.

**What must be measured before choosing between EC:4+2 and EC:8+3?**

Rebuild time must be computed from a measured single-drive rebuild read rate before choosing a scheme.

**Under what condition does EC:8+3's predictability advantage hold?**

EC:8+3's predictability advantage holds only if rebuild concurrency is capped.

**What does the thesis cite for EC:8+3's read-amplified rebuild fan-out?**

The thesis cites ~2.2x read-amplified rebuild fan-out for EC:8+3.

**What Ceph guidance is noted regarding large k values?**

Ceph guidance also discourages k > 8 in most cases.

## Quick answers

| What is the pass/fail threshold for rebuild recovery? | The 4-hour RPO is the pass/fail threshold for full-cluster or multi-drive failure recovery. |
| --- | --- |
| How does the shards-read-per-object differ between the two schemes? | EC:4+2 reads 4 shards per object during rebuild, while EC:8+3 reads 8 shards per object, doubling per-object rebuild read fan-out. |
| What must be measured before choosing a scheme? | Rebuild time must be computed from a measured single-drive rebuild read rate before choosing a scheme. |
| What condition is required for EC:8+3's predictability advantage? | EC:8+3's predictability advantage holds only if rebuild concurrency is capped. |
| When does a scheme qualify against the threshold? | A scheme qualifies only if its computed rebuild time (drive read rate x shards-read x TiB-by-shard workload) completes within 4 hours. |

Also worth reading: **Erasure coding vs 3x replication for petabyte durability tradeoffs**: [Erasure coding vs 3x replication](https://x-oss.com/blog/erasure-coding-vs-3x-replication-for-petabyte-durability-tradeoffs.php) · **Cold storage costs: Glacier Instant Retrieval vs Deep Archive at 50TB (2026)**: [Cold storage costs: Glacier Instant](https://x-oss.com/blog/cold-storage-costs-glacier-instant-retrieval-vs-deep-archive-at-50tb-2026.php) · **Cloud storage failover 2026: Amazon S3 5 min RPO vs Azure geo-redundant 15 min — pick S3**: [Cloud storage failover 2026: Amazon](https://x-oss.com/blog/cloud-storage-failover-2026-amazon-s3-5-min-rpo-vs-azure-geo-redundant-15-min-pick-s3.php)

### Related reading

- [Erasure coding vs 3x replication for petabyte durability tradeoffs](https://x-oss.com/blog/erasure-coding-vs-3x-replication-for-petabyte-durability-tradeoffs.php)
- [Object storage costs compared: 2026 500TB 12-drive Erasure Coding (EC:4) vs cloud](https://x-oss.com/blog/object-storage-costs-compared-2026-500tb-12-drive-erasure-coding-ec4-vs-cloud.php)
- [2026 12+4 Erasure 1PB Scorecard: Price, Speed, AFR Switch](https://x-oss.com/blog/2026-124-erasure-1pb-scorecard-price-speed-afr-switch.php)
- [Synchronous human approval gates and p99 latency: a verify-before-commit guide](https://x-oss.com/blog/synchronous-human-approval-gates-and-p99-latency-a-verify-before-commit-guide.php)
- [Agent State Storage Tiering: A Measurement-First Decision Guide](https://x-oss.com/blog/agent-state-storage-tiering-a-measurement-first-decision-guide.php)
- [S3 Replication to Brazil: Fortaleza vs São Paulo Latency and BRL/GB Egress](https://x-oss.com/blog/s3-replication-to-brazil-fortaleza-vs-so-paulo-latency-and-brlgb-egress.php)

### Latest

- [Synchronous human approval gates and p99 latency: a verify-before-commit guide](https://x-oss.com/blog/synchronous-human-approval-gates-and-p99-latency-a-verify-before-commit-guide.php)
- [Agent State Storage Tiering: A Measurement-First Decision Guide](https://x-oss.com/blog/agent-state-storage-tiering-a-measurement-first-decision-guide.php)
- [S3 Replication to Brazil: Fortaleza vs São Paulo Latency and BRL/GB Egress](https://x-oss.com/blog/s3-replication-to-brazil-fortaleza-vs-so-paulo-latency-and-brlgb-egress.php)

Canonical: https://x-oss.com/blog/disk-rebuild-times-2026-minio-erasure-coding-ec42-vs-ec83-4-hour-rpo-or-fail.php
Markdown: https://x-oss.com/blog/disk-rebuild-times-2026-minio-erasure-coding-ec42-vs-ec83-4-hour-rpo-or-fail.php/index.md