RAID Layout and Rebuild Exposure on a 24-Bay Database Array

For the RAID 5 option, 22 drives with one parity per array gives 21 data drives x 4 TB = 84 TB, so the raw claim is right, but that figure ignores filesystem overhead, snapshot reserve, and the fact that 84 TB is decimal drive capacity rather than what the database sees. More important, RAID 5 leaves a single parity disk: while rebuilding a 4 TB member the array has no tolerance for a second fault, and the rebuild reads about 84 TB, or 6.7 x 10^14 bits. Against a 10^15 unrecoverable-read specification that is roughly a coin-flip chance of hitting an unreadable sector mid-rebuild, which is not defensible against a 99.9 percent commitment. RAID 6 with the same 22 drives gives 20 x 4 TB = 80 TB, 4 TB short of the approved figure, but survives one additional fault and can absorb a read error during rebuild using the second parity. RAID 10 across 24 drives gives 12 mirrored pairs = 48 TB, half the capacity, with rebuilds that only touch a single 4 TB mirror partner and much better random write behavior for 70/30 OLTP. Practical answer: RAID 10 for the database volume if 48 TB suffices, RAID 6 on the backup staging volume, and go back to finance because the 84 TB plan is not the safe design.

No. Rebuild time is drive size divided by the effective rebuild throughput, and the controller throttles rebuilds so host I/O is not starved. A 4 TB 7200 rpm drive streaming sequentially at roughly 150 MB/s takes over seven hours even at full speed; with a rebuild rate held to 30 to 50 percent under OLTP plus the nightly backup stream, 12 to 20 hours is realistic. The four-hour expectation confuses rebuild completion with array availability: the array stays online and serving during a rebuild, so the operationally meaningful targets are surviving the rebuild window and restoring redundancy quickly. Levers that genuinely shorten exposure: use smaller drives (1.2 TB 10K or 2 TB) so the copy is shorter, choose RAID 10 so only a mirror partner must be copied, use predictive-failure telemetry to replace drives before they drop, keep hot spares already spun up and assigned to the right array, and move the backup stream off these spindles. Publish the real rebuild estimate in the runbook so nobody plans a maintenance window around a myth.

A spare only helps if it can be seen by, and used to replace a failed member of, the array it serves. A spare sitting in a shelf that loses its SAS link, or in a different shelf from the failed drive, may never be claimed; a global spare can also be grabbed by the wrong array in a multi-array configuration. Put one spare in the head chassis and one in each expansion shelf, and use dedicated spares for the critical database array so the backup volume cannot consume them. Note that spare drives spin and wear, so rotate them on a schedule. On the controller: a single controller with a 2 GB cache and no battery or flash-backed module means write-back caching is unsafe after an unplanned power loss, and this site has had two in a year. Set the cache policy to write-through until a cache protection module is installed, or accept the risk only with explicit sign-off, and confirm the array is configured to detect and handle a lost-write situation on boot rather than silently discarding cached data.