RAID Sizing Calculator

RAID layout:

Supported: RAID 0/1/5/6/10/50/60 and RAID-Z1/Z2/Z3.

Drives per group:

Enter members per group, e.g. mirror width for RAID 1 or 10 drives for each RAID 6 group.

drives

Group count:

Enter whole groups, e.g. 3 vdevs or 2+ groups for RAID 50/60.

groups

Drive size:

Example: 18 TB; select decimal TB/GB or binary TiB/GiB to match vendor specs.

Dedicated hot spares:

Use 0 when every installed drive is active; value must stay below total drive count.

drives

{{ message }}

Planning fill target: {{ formatPct(target_fill_pct, 0) }}

Typical production planning: 70-85%; 100% means no operating headroom.

Target usable capacity:

Enter 0 to disable target matching; otherwise use TB/TiB/PB/PiB.

Chassis slots:

Enter total bays in the chassis or shelf set, e.g. 24; use 0 to skip bay-fit checks.

bays

Keep empty bays free:

Use 0 when all chassis bays may be filled by the current or target plan.

bays

Expansion shelf size:

Enter a shelf/drawer size such as 12, 24, or 60; use 0 to report bays only.

bays

Metadata overhead:

Enter percent overhead such as 2-4 for appliance metadata, or 0 if already accounted for.

System reserve per drive:

Enter GB reserved on each installed drive, e.g. 10; use 0 when no platform carve-out applies.

Expected read ratio: {{ formatPct(read_ratio_pct, 0) }}

Enter read share as percent, e.g. 70 for a 70% read / 30% write workload.

Random IOPS per drive:

Enter sustained random IOPS per drive; use 0 to omit performance estimates.

IOPS

Rebuild throughput:

Enter sustained MB/s after controller limits; use 0 to omit rebuild exposure estimates.

MB/s

Rebuild contention allowance: {{ rebuild_contention_pct }}%

Accepted range: 0-90%; higher values produce longer rebuild windows.

AFR per drive:

Enter annualized failure rate as percent, e.g. 0.8 for 0.8% per drive per year.

URE rate model:

Select a bits-read error-rate tier, or skip when media URE data is unavailable.

Display precision:

Accepted range: 0-6 decimal places; calculations keep full internal precision.

Metric	Value	Planning Context	Copy
{{ row.label }}	{{ row.value }}	{{ row.note }}

Layout	Usable (TiB)	Efficiency	Fault Tolerance	Write Penalty	Profile	Copy
{{ row.label }}	{{ row.usableTib }}	{{ row.efficiency }}	{{ row.faultTolerance }}	{{ row.writePenalty }}	{{ row.profile }}

Path	Configuration	Provisioned usable	Target delta	Bay delta	Sizing note	Copy
{{ row.label }}	{{ row.configuration }}	{{ row.usable }}	{{ row.targetDelta }}	{{ row.bayDelta }}	{{ row.note }}

Drive size	Provisioned usable	Delta vs current	Sizing signal	Rebuild window	Market note	Copy
{{ row.driveSize }}	{{ row.usable }}	{{ row.deltaVsCurrent }}	{{ row.sizingSignal }}	{{ row.rebuild }}	{{ row.note }}

Field	Value	Copy
{{ row.label }}	{{ row.value }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

A storage purchase starts with drive labels, but a dependable RAID plan starts with drive roles. Some capacity carries data, some carries parity or mirror copies, some sits idle as a hot spare, and some should remain unallocated so the storage system can scrub, rebuild, snapshot, and absorb normal growth without running out of breathing room.

The same set of disks can produce very different answers. Twelve 20 TB drives in RAID 0 advertise every drive to the workload and lose the array when one member fails. The same twelve drives in RAID 6 spend two drive-equivalents on parity, while a mirror or RAID 10 layout trades more raw space for simpler recovery behavior. RAID 50 and RAID 60 add another decision because group width and group count both affect fault tolerance, usable capacity, and future expansion steps.

RAID-Z uses parity inside ZFS vdevs rather than a traditional controller layout. RAID-Z1, RAID-Z2, and RAID-Z3 broadly follow one, two, and three parity-drive equivalents, but ZFS can also change apparent capacity through record size, ashift, compression, snapshots, metadata, and slop space. That is why RAID sizing is best treated as a planning ledger rather than a promise that every byte in the arithmetic will appear exactly the same way on the deployed system.

Stacked capacity bar showing raw drive total split into provisioned usable capacity, protection, spares, and headroom.

Many capacity surprises come from mixing unlike numbers. Drive vendors usually label disks in decimal terabytes, while many operating systems and appliances report binary tebibytes. A hot spare may not hold normal data, yet it still takes a slot and a purchase line. A high fill target can make the usable number look efficient while leaving too little margin for rebuilds, snapshots, scrub activity, or a forecast that was only slightly wrong.

Common RAID sizing terms and why they change usable capacity
Sizing term	Plain meaning	Why it changes the plan
Group width	Drives that share one mirror, parity set, or RAID-Z vdev.	Wider parity groups improve capacity efficiency but can lengthen rebuild time and URE exposure.
Group count	How many equal groups are striped together.	Adding full groups is often cleaner than reshaping one existing group.
Protection overhead	Drive-equivalent capacity used for parity or mirrors.	It is the main difference between raw capacity and data capacity.
Operating headroom	Unallocated capacity kept back by a fill target.	It gives filesystems and operations room to repair, scrub, rebalance, and grow.

RAID sizing also has a hard boundary: redundancy is not a backup. Mirroring and parity can keep a service available through selected drive failures, but they do not undo deletion, application corruption, controller faults, enclosure loss, ransomware, or a restore plan that has never been tested. Capacity planning is strongest when the usable number is read beside fault tolerance, rebuild exposure, chassis fit, and an independent backup policy.

How to Use This Tool:

Build the physical layout first, then add policy choices such as fill headroom, chassis reserve, and risk assumptions.

Choose RAID layout. The supported layouts are RAID 0, RAID 1, RAID 5, RAID 6, RAID 10, RAID 50, RAID 60, RAID-Z1, RAID-Z2, and RAID-Z3.
Enter Drives per group and Group count. If a validation message appears, fix the layout minimum before reading the tables, such as RAID 6 needing at least 4 drives per group or RAID 50 and RAID 60 needing at least 2 groups.
Set Drive size with the right unit. Use TB or GB for decimal vendor labels, and TiB or GiB when the starting number already comes from an operating-system or appliance report.
Enter Dedicated hot spares apart from active drives. The result should show the spare reservation separately from protection overhead and planned usable capacity.
Adjust Planning fill target. A 70 to 85 percent target leaves operating headroom; 100 percent removes that modeled headroom margin.
Open Advanced for target capacity, chassis slots, empty-bay reserve, expansion shelf size, metadata overhead, system reserve per drive, read ratio, drive IOPS, rebuild throughput, AFR, URE rate, or display precision.
Check the summary and RAID shelf visual. The drive count, hot spares, usable portion, and fault-tolerance posture should match the design you meant to model.
Use RAID Sizing Ledger for capacity accounting, RAID Layout Ladder for same-drive comparisons, RAID Growth Path after setting a target, and RAID Drive Market when current-slot drive-size options matter.

Interpreting Results:

Treat Provisioned usable capacity as the planning number for quotas, backup windows, procurement notes, and service promises. Raw installed capacity remains useful for purchasing, but the ledger shows why raw capacity is not the amount that should be promised to workloads.

RAID sizing outputs and how to interpret them
Output	What to check	False-confidence warning
Provisioned usable capacity	Use the TB and TiB pair to compare vendor drive labels with operating-system reports.	A large usable number is weak if the fill target leaves no repair, scrub, or growth room.
Plan posture	Compare No fault tolerance, Capacity-biased profile, Balanced profile, and Resilience-biased profile against the workload's recovery needs.	A green posture is not a data-loss guarantee; enclosure, controller, operator, and backup risks remain.
Fault tolerance per group	Read it per group or vdev, not as a promise that any arbitrary drives can fail anywhere.	RAID 10 can have a higher best case than guaranteed case because mirror-pair placement matters.
Chassis fit and Growth window	Check occupied bays, reserved empty bays, and whether another full group fits before choosing drive sizes.	Capacity can meet the target while the chassis still fails the bay budget.
Target delta and Recommended growth path	Use these only after setting Target usable capacity. The search keeps the same layout and current reserve assumptions.	A same-layout match may be easier to reason about, but it is not a vendor-approved expansion procedure.
URE event chance, annual loss probability, and MTTDL	Read them as rough risk signals when URE rate, AFR, and rebuild throughput are set.	They do not replace platform reliability data, burn-in results, monitoring, or restore tests.

When results look surprisingly optimistic, verify four items before acting on them: the unit beside Drive size, the number of active groups, whether hot spares are separate from data drives, and whether Planning fill target still matches the operating policy you actually use.

Technical Details:

RAID sizing starts by reducing each group to data-bearing drive equivalents. RAID 0 treats every drive as data. RAID 1 treats each mirror group as one data drive plus mirror copies. RAID 10 uses complete two-drive mirror pairs and leaves an odd leftover drive unused in the group. Single-parity layouts reserve one drive-equivalent per group, dual-parity layouts reserve two, and RAID-Z3 reserves three.

Capacity is then adjusted in a fixed order. Hot spares are removed from the layout data capacity, metadata overhead is taken as a percentage after spare deduction, system reserve is taken as a decimal GB amount per installed active drive, and the fill target converts physical usable space into a planned allocation number.

Formula Core

The main capacity equation calculates the space that should be planned for workloads after redundancy, spares, reserves, and fill policy.

C_{planned} = (C_{layout} - C_{spare} - C_{metadata} - C_{system}) \times \frac{P_{fill}}{100}

Capacity formula symbols used by RAID sizing
Symbol	Meaning	How it is derived
`C_layout`	Layout data capacity before hot spares and reserves.	Data drives per group x group count x drive size in bytes.
`C_spare`	Dedicated hot spare reservation.	Applied spare count x drive size in bytes.
`C_metadata`	Optional filesystem or appliance overhead.	Post-spare capacity x Metadata overhead percent.
`C_system`	Optional fixed platform reserve.	System reserve per drive in decimal GB x total active drive count.
`P_fill`	Planning fill target.	Slider value from 10 percent to 100 percent.

For example, 10 drives per group x 3 groups of 18 TB drives in RAID 6 gives 8 data drives per group, so layout data capacity is 432 TB. One hot spare removes 18 TB, and an 80 percent fill target turns the remaining 414 TB into 331.20 TB, displayed as about 301.19 TiB before optional metadata or system reserves.

Layout Geometry

RAID layout geometry and write penalty rules
Layout family	Data drives per group	Guaranteed faults per group	Write penalty used
RAID 0	All drives	0	1:1
RAID 1	1	Width - 1	Mirror width:1
RAID 10	floor(width / 2)	1 guaranteed, up to one per mirror pair	2:1
RAID 5, RAID 50, RAID-Z1	Width - 1	1	4:1
RAID 6, RAID 60, RAID-Z2	Width - 2	2	6:1
RAID-Z3	Width - 3	3	8:1

Risk and Performance Estimates

Optional estimates use simple planning formulas. They are most useful for comparing assumptions, not for certifying a storage platform.

Optional RAID sizing formulas for performance and reliability estimates
Estimate	Rule used	Interpretation boundary
Mixed random IOPS	Total drive IOPS x read share + total drive IOPS / write penalty x write share.	Enabled only when Random IOPS per drive is greater than 0.
One-drive rebuild time	Drive size divided by effective MB/s after Rebuild contention allowance.	Enabled only when Rebuild throughput is greater than 0.
URE event chance	1 - exp(-URE rate x bits read), with bits read based on one-drive rebuild exposure.	Enabled only when a URE rate model is selected.
Approximate annual loss probability	Combination count for one more failure than guaranteed tolerance, scaled by rebuild exposure and group count.	Enabled only when AFR and Rebuild throughput are both greater than 0.

Status Boundaries

RAID sizing status boundary rules
Status	Condition	Meaning
No fault tolerance	Selected layout is RAID 0.	Any member drive failure can lose the array.
Resilience-biased profile	Guaranteed faults per group >= 2, fill target <= 80 percent, and URE chance is unset or below 10 percent.	The modeled setup favors redundancy and headroom.
Balanced profile	Guaranteed faults per group >= 1 and fill target <= 85 percent.	The modeled setup keeps redundancy and moderate headroom.
Capacity-biased profile	Any other valid redundant setup.	Capacity, high fill, or weaker tolerance is driving the result.

Limitations and Accuracy Notes:

The calculator gives a deterministic planning estimate from the values you enter. Final deployable capacity still depends on the exact storage platform, controller, filesystem, firmware, enclosure design, replacement process, and support matrix.

RAID-Z capacity is approximate because ZFS can vary space use with record size, ashift, metadata, slop space, snapshots, compression, and vdev behavior.
Hot spare behavior differs by controller and platform. A spare must be large enough and available to the rebuild process.
URE, AFR, annual loss probability, and MTTDL are heuristic planning signals. They are not warranties, field-failure predictions, or substitutes for monitoring.
RAID protects against some drive-failure scenarios, not against every outage or data-loss cause. Keep independent backups and test restores.

Advanced Tips:

Set Target usable capacity before checking RAID Growth Path; otherwise the growth rows compare layouts without a procurement target.
Use Chassis slots and the empty-bay reserve together. A capacity plan can meet the target and still fail the bay budget after reserve bays are protected.
Enter Metadata overhead and System reserve per drive only when they match a real platform policy. Generic reserves can double-count space that the appliance already reports as unavailable.
Keep Random IOPS per drive and Expected read ratio consistent when comparing layouts. A write-heavy workload makes parity write penalty more visible.
Use Rebuild throughput, Rebuild contention allowance, AFR, and URE rate as comparison assumptions, not as field reliability predictions.
When RAID Drive Market points to a larger sampled drive size, confirm controller limits, sector size behavior, and replacement availability before buying a full shelf.

Worked Examples:

Dual-parity NAS replacement

A common first pass is RAID 6 with 10 drives per group, 3 groups, 18 TB drives, 1 dedicated hot spare, and an 80 percent Planning fill target. RAID Sizing Ledger reports Provisioned usable capacity at about 301.19 TiB (331.20 TB), Effective efficiency near 61.33 percent, and Fault tolerance per group as 2 drive(s)/group. That is the number to compare with service allocations, while Raw installed capacity remains 540 TB for purchasing.

High fill target warning

Keeping the same RAID 6 layout but moving Planning fill target to 90 percent raises Provisioned usable capacity to about 338.84 TiB (372.60 TB). Plan posture changes to Capacity-biased profile because the model has less operating headroom, even though dual-parity fault tolerance is unchanged.

Target and chassis planning

For a 24-bay chassis, set Chassis slots to 24 and reserve 2 empty bays before entering a Target usable capacity. RAID Growth Path then checks whether a same-layout match can stay inside the bay budget. If the result says Needs +bays in Chassis fit or Target delta remains short, compare RAID Drive Market before adding another shelf.

Validation recovery

If RAID 60 is selected with Group count set to 1, the result disappears and the error says RAID 60 needs at least 2 groups. Increase Group count to 2 or choose a non-nested layout before using the ledger or chart tabs.

FAQ:

Why is usable capacity so much lower than the raw drive total?

The ledger subtracts parity or mirror overhead, dedicated hot spares, optional metadata reserve, optional system reserve, and the Planning fill target. Raw installed capacity counts all active drives before those deductions.

Should I enter TB or TiB?

Use TB or GB for drive labels and vendor datasheets that use decimal units. Use TiB or GiB when the input comes from an operating system or appliance report that already uses binary units.

Why does RAID 10 show guaranteed and best-case fault tolerance?

RAID 10 uses mirror pairs. One failed drive per group is guaranteed in the model, but more failures may survive when they land in different mirror pairs. Two failed drives in the same pair can still lose data.

Why did the results disappear after I changed a field?

Validation errors hide the result until the geometry is valid again. Check the message under the core fields, such as a layout needing more drives per group, RAID 50 or RAID 60 needing at least 2 groups, or hot spares being equal to or greater than total drive count.

Can the risk estimates replace vendor reliability sizing?

No. URE event chance, annual loss probability, and MTTDL depend on simplified AFR, URE, rebuild throughput, and contention assumptions. Use them to compare scenarios, then confirm the final design with the storage platform's own sizing and support guidance.

Does the calculator upload my storage plan?

The capacity, chart, and export values are computed in your browser after the page loads. If you share or bookmark a configured URL, treat any visible capacity and chassis settings in that URL as sensitive internal planning data.

Glossary:

AFR: Annualized failure rate, entered as a per-drive yearly percentage for the optional annual loss estimate.
Fill target: The planned percentage of post-reserve usable capacity that may be allocated to workloads.
Hot spare: A standby drive reserved for rebuild or replacement use instead of normal data capacity.
MTTDL: Mean time to data loss, shown here as a rough planning inverse of the annual loss probability.
RAID group: A same-layout set of drives that share the mirror or parity rule before groups are multiplied.
RAID-Z vdev: A ZFS parity group that may use RAID-Z1, RAID-Z2, or RAID-Z3 protection.
URE: Unrecoverable read error, a media read failure that can matter during rebuilds.

References:

What is Mirroring?, Storage Networking Industry Association.
Supported Levels for Intel RAID Controllers, Intel, last reviewed September 3, 2024.
RAIDZ, OpenZFS documentation.
RAID-Z Storage Pool Configuration, Oracle Solaris documentation.
Definitions of the SI units: The binary prefixes, NIST.
Exos 2X18 SAS Product Manual, Seagate.

RAID Sizing Calculator

Provisioned Usable RAID Capacity

Current result

How to Use This Tool:

Interpreting Results:

Technical Details:

Formula Core

Layout Geometry

Risk and Performance Estimates

Status Boundaries

Limitations and Accuracy Notes:

Advanced Tips:

Worked Examples:

Dual-parity NAS replacement

High fill target warning

Target and chassis planning

Validation recovery

FAQ:

Glossary:

References: