How Long One 22TB Drive Takes to Rebuild

The figure that decides whether an array survives its first bad week is not printed on the drive. Capacity sits on the label, the interface sits in the datasheet, workload ratings sit in the footnotes — but the number that matters is a duration, and it belongs to the system built around the drive rather than to the drive itself.

A model such as the WD Ultrastar WUH722422ALE6L4 identifies a 22TB SATA drive; it cannot identify your rebuild time. That number will be produced by your parity geometry, your controller's rebuild policy, your spare bay and the traffic your users generate at the worst possible hour. All four are settled before a drive fails. Three of them are settled by decisions made at purchase.

Rebuild time is the decision variable

The length of the unprotected window should decide the purchase, and it is the one quantity large-drive buyers rarely write down. Redundancy is insurance with a deductible paid in hours: a member failure does not destroy data, it starts a countdown during which the array has no margin left for a second fault, an uncorrectable read, or a power event timed badly.

Every other number on a storage quotation is a capacity or a speed. This one is the time your service spends one failure away from an outage — and unlike most risk figures, it can be estimated in advance with arithmetic you can show to a colleague. The capacity and rebuild planning questions worth settling before an order are mostly variations on this single variable.

Four things set how long a rebuild runs

Only one of the four is even partly printed in the drive's specification; the others come from the array and from how it is operated.

The first is the size of the job. In parity RAID, losing one member means every surviving member is read in full and one member's worth of data is written; a mirror copies what it actually holds. A wide array of large members moves more bytes during a rebuild than a narrow array of small ones, even when total usable capacity matches.

The second is the throughput the array can spare. Controllers and firmware usually cap rebuild rate to protect production performance, and that cap is a policy setting rather than a property of the disk. What counts is the rate during your busiest hour, not the quiet one.

The third is the slowest surviving member. A rebuild advances no faster than the weakest drive taking part; one member with marginal sectors can stall the transfer repeatedly, and the average health of the array is irrelevant when a single bad region sets the pace.

The fourth is error handling. Retry policy, timeouts and a post-rebuild verification pass are where clean arithmetic turns into a range. A linear copy is the best case. Deep recovery and verification are the normal case on members that have been spinning for years.

Estimating your own window

The exposure window can be estimated with one division and three corrections, using measurements from your own array rather than any published duration.

1. Measure the rate the array actually gives a rebuild while serving normal traffic — read the platform counters during a scheduled scrub, or time a deliberate member removal in a lab array of the same geometry.
2. Divide the bytes that must be re-derived by that measured rate, counting the read side and the write side separately where your geometry treats them differently.
3. Correct for the worst hour. Use peak-load throughput, then add the platform's verification pass if one follows the rebuild.
4. Correct for the second clock. Add the time between the failure and the moment the replacement is seated; in many shops this gap is a larger share of the exposure than the copy itself.
5. Check the result against a practice run. One canary array, with a member pulled on purpose under representative load, is worth more than any estimate.

What comes out is a duration you can defend, not a promise. Multiply it by the number of arrays you operate and you get the vulnerable array-hours each incident creates; weigh that against what the service can tolerate and the purchase decision largely makes itself. How a single large drive changes the risk profile of an entire array is set out in this note on single-drive risk.

What each mitigation actually costs

Every mitigation either shortens the window or removes the consequence of it, and each is paid for in a different currency.

Wider redundancy — RAID 6 or an erasure-coded layout — removes the cliff where a second member failure ends the story. It costs one member's worth of usable capacity, some write throughput, and more computation during the rebuild. A hot spare shortens the gap before the rebuild starts, not the rebuild itself; its cost is a bay, a drive that does nothing else, and the power to keep it spinning. Smaller members in larger numbers shrink each individual job while multiplying the number of failure events the array will see — a real trade, not a free win. Pre-deployment stress testing adds no rebuild speed at all, but it removes weak members from the population before they can take part in one; the risk-based stress testing guide explains how long that run should be.

Backup and restore is the honest fallback, and the most mispriced one. Where restore time exceeds the rebuild window, backup is not the mitigation it appears to be; where it has never been timed, it is a hope with a schedule attached.

Three rules carry across all of these. When the measured window outlasts what the service can run unprotected, change the geometry or the member size in the order, not the incident procedure. When the array must keep full performance through a rebuild, plan with peak-hour throughput and expect the worst. When a chassis has a single free bay, a hot spare in it buys more than any faster model of the same size.

Two decisions that belong on the purchase order

The failure budget and the recovery path are purchase-time decisions, because everything after the first failure is reaction.

The failure budget states how many simultaneous member losses the array must survive and what performance the service guarantees with one member down. That single sentence chooses the geometry, the member size and whether a spare sits inside the chassis.

The recovery path states what sits on the shelf, who is allowed to seat it, which restore has actually been timed, and what the platform side confirms in writing about rebuild behaviour: rate policy under load, error handling, and whether verification follows the copy. A datasheet will not answer these, and a verbal answer will not survive a bad week. Ask for the confirmation with the order, together with the workload rating the drives are expected to run at.

Why the arithmetic has to happen before the failure

The window is fixed when the drives are bought, and a failure only reveals it. Member size, count, geometry and spare bays are locked in by the purchase, and the platform choice fixes the rebuild policy options; after the first failure the remaining choices are emergency ones — buying capacity under pressure, running degraded, or restoring from backup on a clock nobody tested.

That is the whole argument for doing the division first. Planning the failure before it happens is cheaper than answering it in an incident channel, and the arithmetic is the part that can be done calmly. Who wants to run that division at three in the morning with the array degraded? The rest of the procurement notes in the insights library follow the same principle: decisions that can be priced at order time should not be left to the worst hour.