Raw capacity and decimal terabytes

Raw capacity is disk count multiplied by the smallest participating disk size. The input uses manufacturer-style decimal terabytes, where one TB is one trillion bytes. Many operating systems display tebibytes or label binary quantities as TB, so the visible number after formatting can be smaller even before RAID overhead.

If disks have unequal sizes, conventional RAID groups commonly use only the capacity of the smallest member from each disk. Enter that smallest usable size, not the sum printed on labels. Vendor-specific pooling can behave differently and should be modelled with the vendor’s documented layout rather than this equal-disk formula.

RAID 0 and RAID 1

RAID 0 stripes data across disks and uses all arithmetic capacity, but it provides no redundancy. Failure of one member can make the entire array unusable. Faster or larger does not mean protected. Do not store the only copy of important data on a RAID 0 array.

RAID 1 keeps identical copies. This calculator models one mirror set with usable capacity equal to one disk, even if more than two members are selected. A mirror can survive failures only while at least one complete readable copy remains. Controller implementations and multiway mirrors should be confirmed before relying on the displayed tolerance.

Parity in RAID 5 and RAID 6

RAID 5 reserves capacity equivalent to one disk for distributed parity, giving number of disks minus one times disk size. It can tolerate any one member failure in the simplified model. RAID 6 uses dual parity, reducing capacity by two disks and tolerating any two member failures in the simplified model.

Parity does not make a degraded array safe indefinitely. Rebuild reads every surviving member heavily, and another error or failure can prevent recovery. Large disks can take a long time to rebuild. Scrubbing, monitoring, tested replacement procedures and current backups are part of the design, not optional extras after a warning appears.

RAID 10 failure combinations

RAID 10 mirrors disks in pairs and stripes across those pairs. Arithmetic capacity is half of raw capacity and an even count of at least four is required here. It can survive one failure in every mirror pair, but it cannot survive both members of the same pair failing.

That distinction is why the result avoids saying RAID 10 tolerates any two disks. With four disks, some two-disk failure combinations leave one copy in each pair while another combination destroys a pair. Identify the physical and logical pairing when labelling bays or planning maintenance.

Reserve and performance headroom

The reserve percentage subtracts a planning margin from RAID arithmetic capacity. Filesystems, databases and flash devices can perform poorly or fail operations when nearly full, and snapshots need room to grow. A reserve is not parity overhead and does not increase failure tolerance; it is unused operational headroom.

Choose reserve according to workload, snapshot retention, thin provisioning and vendor guidance. Monitor both physical pool use and logical allocation. A thin-provisioned volume can appear to have space while the underlying pool approaches exhaustion, so the planned ceiling should be connected to alerts and capacity forecasts.

RAID is not backup

RAID can maintain service through some disk failures. It does not protect against accidental deletion, ransomware, filesystem corruption, controller failure, theft, fire, power events or an administrator overwriting data. Mirroring faithfully copies many logical errors to every member.

Maintain independent, versioned backups with at least one copy separated from the array and its credentials. Test restoration of representative files and whole services. A backup that has never been restored is an unverified hope, regardless of the RAID level.

Hot spares and replacements

A hot spare is not included in the entered active disk count unless it is actually part of the data/parity layout. It normally waits to replace a failed member and therefore consumes a bay and purchase cost without adding usable capacity. Distributed spare schemes can differ.

Replacement disks should meet capacity and compatibility requirements. A nominally equal model can expose slightly fewer sectors and be rejected. Check sector format, interface, firmware, drive class and controller support. Replace the identified failed member only after verifying bay mapping; pulling a healthy disk from a degraded set can cause data loss.

Filesystem and vendor overhead

After RAID arithmetic, partition tables, filesystem metadata, checksums, journals, deduplication tables, object replicas and snapshots can further reduce available user space. Compression may increase effective capacity for compressible data, while already compressed media changes little. Do not budget guaranteed savings from an optimistic compression ratio.

Vendor appliances can reserve system partitions on every drive or use erasure coding that does not map directly to classic RAID. Use this calculator for first-pass classic arithmetic, then compare the deployment guide and management interface. Document why the production number differs so future capacity planning uses the correct layer.

Design review checklist

Confirm workload, availability target, recovery-point and recovery-time objectives, disk failure assumptions, rebuild duration, controller redundancy, power protection, monitoring, spares, filesystem behaviour and backup restoration. Capacity is only one row of the design. A cheaper layout that cannot meet recovery needs is not economical.

Record raw bytes, displayed units, active members, spare members, parity or mirror overhead, reserve and current usage separately. Test a simulated member failure in a safe environment and verify alert delivery. Production resilience should be demonstrated before a real failure, not inferred from a level name.

Plan recovery before deployment

Document which disks, controller, firmware and layout create the array, then test alerting and a restore from an independent backup. Usable capacity is only one design constraint. Rebuild duration, unrecoverable read errors, correlated drive failure, enclosure loss, ransomware and accidental deletion can make an apparently redundant array unavailable.