Redundancy usually gets discussed as a binary. You have it or you do not, the design review ticks the box, everyone moves on. The far more useful question is what happens during the window when you have lost some of it and are trying to get it back.
A rebuild is not a background task. That is the mental model most people carry, and it is wrong in a way that only becomes obvious under load. A rebuild competes with production for precisely the resources production needs, and it does so at the exact moment when the system is least able to absorb another failure. It is the worst possible time for an expensive job to start, and it is the only time it can run.
The properties worth knowing before you need them
How long it takes at your actual capacity, not the datasheet's. Rebuild time scales with how full the thing is. Datasheets are not full, and neither is the lab.
What it does to latency while it is running. If tail latency triples during a rebuild, that is a production event, even though nothing has technically failed and no alarm has fired. Your customers will experience it as an outage regardless of what your status page believes.
What a second failure during that window costs you. This is the number that actually determines whether your redundancy scheme is adequate, and it is almost never the number quoted in the design review, because it is the one that requires you to multiply a duration by a probability and say the result out loud.
Why this matters more than it used to
Capacities grew faster than rebuild throughput. They have been doing so for years, quietly, while the mental model everybody carries stayed where it was.
That is the part I find genuinely interesting: nothing changed conceptually. The scheme that was comfortable at one capacity can be meaningfully risky at ten times that capacity with no other change to the design, no bug introduced, and no decision made by anyone. The design did not degrade. The world moved underneath it.
Which is a good argument for re-deriving your assumptions on a schedule rather than when something breaks. The number that was fine when you wrote it down is not automatically still fine, and nothing in the system is going to tell you.