NAS & RAID Capacity Calculator

Worked examples

These are this calculator’s own outputs, computed with the same formula the tool runs in your browser — so you can see a real answer without touching a single input.

A 4-bay NAS (Synology DS423+ / QNAP / DIY) with four 4 TB drives in RAID 5 — this is the calculator’s own default state on page load

• Inputs: Number of drives = 4, Capacity per drive = 4, Unit = TB, RAID level = RAID 5 / RAIDZ1
• Result: Usable space 12.0 TB | Raw capacity 16.0 TB (across 4 × 4 TB) | Overhead (parity) 25%, 1 drive reserved | Guaranteed drive failures tolerated 1 (amber), 1 drive can fail safely | Usable on ZFS 10.8 TiB (after the 128 GiB slop reserve, before padding and metadata)

A 6-bay homelab NAS with six 8 TB drives in RAID 6 / ZFS RAIDZ2 — the double-parity setup most people move to once the array gets big

• Inputs: Number of drives = 6, Capacity per drive = 8, Unit = TB, RAID level = RAID 6 / RAIDZ2
• Result: Usable space 32.0 TB | Raw capacity 48.0 TB (across 6 × 8 TB) | Overhead (parity) 33%, 2 drives reserved | Guaranteed drive failures tolerated 2 (green), 2 drives can fail safely | Usable on ZFS 29.0 TiB (after the 128 GiB slop reserve, before padding and metadata)

A 4-bay box with four 8 TB drives in RAID 10 (two mirrored pairs) — the mirrored-stripe option people pick for faster rebuilds over RAID 5

• Inputs: Number of drives = 4, Capacity per drive = 8, Unit = TB, RAID level = RAID 10
• Result: Usable space 16.0 TB | Raw capacity 32.0 TB (across 4 × 8 TB) | Overhead (parity) 50%, 2 drives reserved | Guaranteed drive failures tolerated 1 (amber), 1 drive can fail safely | Usable on ZFS 14.4 TiB (after the 128 GiB slop reserve, before padding and metadata)

How to use this calculator

Choose the drive count, labeled capacity per drive, unit, and RAID level. Optionally enter the total NAS purchase price in USD for drives and other hardware. The added cards divide that entered total by the selected RAID result’s usable decimal TB and binary TiB; they exclude ZFS padding, metadata, replacements, and electricity. A blank price leaves those cards out, while an entered zero is shown as zero rather than treated as missing.

After the result is valid, Continue to power cost carries the storage plan and any entered upfront price into the operating-cost calculator. Its NAS wattage is a labeled starting estimate because drive capacity and RAID geometry do not determine electrical draw; replace it with measurements from your own unit. The power page keeps the purchase total and its electricity estimate separate, then shows a three-year combined outlay only when a price was entered.

This RAID capacity calculator turns your drive count and drive size into usable storage for every level — RAID 0, 1, 5, 6, 10 and ZFS RAIDZ1/2/3. Select your RAID level, enter how many drives you have and their individual capacity, and it instantly shows usable space, redundancy level, and what happens when a drive fails.

Use the RAID comparison table at the bottom to see all levels side-by-side for your drive count.

Capacity, not performance

The main calculator above calculates capacity, not speed or rebuild duration. Drive count and size alone cannot predict either. The separate worksheets below use explicit span geometry or an entered rebuild rate.

For IOPS/throughput conversion and workload tradeoffs, use the storage-backend worksheet. For a measured rebuild example and the variables that move it, use the six-bay NAS rebuild guide.

RAID 50 and RAID 60 calculator

These nested layouts stripe across multiple parity groups, called spans here. This worksheet assumes equal-size spans and uses the smallest drive size throughout. RAID 50 needs at least two RAID 5 spans of three drives each; RAID 60 needs at least two RAID 6 spans of four. Dell describes those layouts in the PERC technical guide, sections 5.3.6–5.3.7.

The capacity formula is spans × (drives per span − parity per span) × smallest drive TB, with parity per span equal to 1 for RAID 50 or 2 for RAID 60. For two four-drive spans of 8 TB disks, RAID 50 gives 2 × (4 − 1) × 8 = 48 TB; RAID 60 gives 2 × (4 − 2) × 8 = 32 TB. Both use eight disks. Those are nominal capacities before formatting, metadata, reserved space or hot spares; they are not ZFS pool estimates.

Failure location matters. RAID 50 can tolerate one failed drive in each span, assuming the other data remains readable. Two failures in the same span can lose the array, even if another span is healthy. RAID 60 raises that allowance to two per span; three in one span can lose it. Do not multiply the allowance by the span count and treat that as protection from arbitrary failures. Keep a separate backup.

RAID 5 maximum disks and Dell controller limits

The main calculator’s 24-drive input ceiling is a tool limit, not a universal RAID 5 maximum. For one concrete hardware example, Dell’s PERC 9 RAID-level table lists 3–32 disks for RAID 5. That table is scoped to the documented PERC 9 series; it does not establish the limits of every Dell controller, enclosure or software RAID implementation.

For a Dell RAID calculation, first check the exact PERC model’s supported levels, disks per virtual disk, span rules and enclosure support. Then use compatible inputs here for the capacity arithmetic. This worksheet does not certify a configuration as supported by Dell. A supported maximum is not a recommendation to fill it: RAID 5 still has only one drive’s worth of parity, so after one drive fails there is no remaining tolerance for another complete drive failure until redundancy is restored. Choose the group size alongside the recovery plan and backup, rather than from the largest accepted number.

RAID rebuild time calculator: constant-rate scenario

Enter the amount of data that must be rebuilt and an observed sustained rebuild rate. Use the controller’s remaining-work figure when available; do not substitute the array’s usable capacity or a drive’s advertised peak speed. This worksheet does not infer how many bytes your particular controller or filesystem will rebuild.

The arithmetic is seconds = bytes to rebuild ÷ (MB/s × 1,000,000). Here MB/s is decimal; TiB and GiB size inputs use powers of two. For example, 8 TB at a constant 100 MB/s gives 80,000 seconds, about 22.22 hours. Those inputs are an illustration, not a test result. Changing 8 TB to 8 TiB increases the byte count and gives about 24.43 hours at the same entered rate.

The result is a constant-throughput scenario, not a guaranteed ETA, a best-case floor or a prediction of your drives. If the observed rate changes, so does the duration. Recalculate with the remaining bytes and a representative rate after workload or rebuild-policy changes; use the controller’s progress reporting for the actual job. This independent worksheet does not alter the saved NAS capacity plan or its power-cost handoff.

The RAID capacity formula

Every RAID level starts from your raw capacity — drive count (N) times drive size — and reserves some of it for redundancy. The usable-space math is exactly what this calculator runs:

• RAID 0 / JBOD — N x size. No redundancy, 100% usable.
• RAID 1 (mirror) — size. One drive’s worth of usable space; every drive holds a full copy.
• RAID 5 / RAIDZ1 — (N - 1) x size. One drive reserved for parity.
• RAID 6 / RAIDZ2 — (N - 2) x size. Two drives reserved for parity.
• RAIDZ3 — (N - 3) x size. Three drives reserved for parity.
• RAID 10 — (N / 2) x size. Half the raw capacity, in mirrored pairs.

Worked example. Four 4 TB drives (16 TB raw): RAID 5 gives (4 - 1) x 4 = 12 TB usable (25% overhead); RAID 6 gives (4 - 2) x 4 = 8 TB usable (50% overhead); RAID 10 also gives 8 TB usable but rebuilds faster after a failure.

Six 8 TB drives in RAIDZ2 give (6 - 2) x 8 = 32 TB usable.

Those are decimal TB, the way drives are labeled. Your OS reports binary TiB, so a 12 TB result shows as roughly 10.9 TiB — about 7-10% less — before any filesystem overhead.

A ZFS caveat (RAIDZ padding). RAIDZ uses the parity formula above, but real usable capacity on ZFS is usually a little lower than the raw math shows.

RAIDZ rounds every block up to a multiple of (parity + 1) sectors — the “skip blocks” that catch people out — and ZFS also holds back slop space, covered in the next section.

The padding is negligible with the default 128K recordsize on friendly drive counts, but grows with small recordsize/volblocksize on ashift=12 (4K-sector) pools, where small-block zvols (VM disks) can approach mirror-level overhead. So treat the RAIDZ figures here as the parity ceiling; for exact capacity that models skip blocks, use the OpenZFS capacity calculator.

ZFS capacity calculator: what the pool lets you fill

On ZFS, start from the parity math above and take off two things.

The first is the slop reserve.

OpenZFS will not let you fill the last 1/32 of a pool, but its source caps that at 128 GiB, so any pool over 4 TiB gives up about 128 GiB.

The second is units: the card shows binary TiB, the unit your OS reports, as noted above. The Usable on ZFS card does both.

Six 8 TB drives in RAIDZ2 give 32.0 TB of parity-usable space, which is 29.1 TiB. Less the 128 GiB reserve, about 29.0 TiB is left for files. Small pools work differently.

Four 1 TB drives in RAIDZ1 give 3 TB, and there the 1/32 rule applies: a reserve of about 87 GiB leaves about 2.64 TiB.

RAIDZ padding and metadata come off on top, so I’d read the card as a ceiling and plan to the OpenZFS capacity calculator when small records matter.

Choosing a RAID level

Two-drive failure tolerance — RAID 6 or ZFS RAIDZ2. Both survive any two drive failures, so after the first failure the array still has one drive of redundancy while it rebuilds. A second failure in that window leaves it running with none. That covers drives only: deletion, ransomware, a failed controller and a fire still need the backups described below.

Best usable space with one-drive redundancy — RAID 5 or ZFS RAIDZ1. Same parity formula, though ZFS’s real usable capacity runs a little lower once RAIDZ padding is counted (see the ZFS note above); the ZFS version is also safer (no write hole).

Simple mirroring for small arrays — RAID 1 (2 drives) or RAID 10 (4+ drives in mirrored pairs). Lower capacity efficiency but simpler failure recovery and better random read performance.

Maximum space, no redundancy — RAID 0 or JBOD. One drive failure loses everything. Only appropriate for scratch storage or content you have elsewhere.

RAID does not replace backups

RAID protects against drive hardware failure. It does not protect against:

• Accidental file deletion (the deletion propagates across all drives instantly)
• Ransomware (encrypts data on all drives simultaneously)
• Controller failure (the RAID controller itself can corrupt data on failure)
• Fire, theft, or physical disaster

For a complete data protection strategy: RAID for uptime during a drive failure, plus a 3-2-1 backup strategy with at least one off-site copy. The two layers address different failure modes.

Assumptions and sources

• The usable-space formulas (N-1 drives for RAID 5/RAIDZ1, N-2 for RAID 6/RAIDZ2, N/2 for RAID 10) are the definitions of those RAID levels, not estimates; the calculator applies them exactly.
• The ZFS slop reserve follows OpenZFS itself: 1/32 of the pool from the spa_slop_shift default of 5 (zfs(4), module parameters), bounded by spa_max_slop (128 GiB) and spa_min_slop (128 MiB, or half the pool if smaller) in spa_get_slop_space in spa_misc.c, read 2026-09-29. The Usable on ZFS card applies that rule to the parity-usable space, which stands in for ZFS’s own deflated figure, and leaves out the embedded-log adjustment the same function makes, so it is an estimate. RAIDZ skip-block padding is modeled exactly by the linked OpenZFS capacity calculator.
• Minimum drive counts for the ZFS levels follow OpenZFS zpoolconcepts(7), which sets a raidz vdev’s minimum at one more than its parity count: RAIDZ1 2, RAIDZ2 3, RAIDZ3 4. The calculator’s RAIDZ3 row uses that figure. The combined RAID 5/RAIDZ1 and RAID 6/RAIDZ2 rows keep the higher traditional-RAID minimums (3 and 4), since those rows also stand for the non-ZFS levels.
• The decimal-TB versus binary-TiB gap (roughly 7-10%) follows how drive vendors label capacity, as documented in Seagate’s capacity explainer.