RAID capacity calculator

How the numbers are calculated

RAID combines several drives into one volume. Part of the raw space goes to protection: a full copy of the data (mirroring) or recovery information called parity. How much you lose depends only on the RAID level and the number of drives.

With mixed sizes, standard RAID treats every drive as the size of the smallest one.

Rebuild time is the size of one drive divided by the rebuild speed. An 18 TB drive at 150 MB/s takes about 33 hours, and that is with no other work on the array. Under normal load, rebuilds are often two to three times slower. More on the rebuild time page.

Read error during rebuild uses the unrecoverable read error rate from the drive datasheet (1 per 10¹⁴ bits for desktop drives, 1 per 10¹⁵ for NAS and enterprise drives) and the amount of data the rebuild has to read. These are worst-case specs, so treat the figure as an upper bound that shows how the risk grows with drive size.

All figures use decimal terabytes, the way drive makers label their drives (1 TB = 1,000,000,000,000 bytes).

Which RAID level to choose

There is no single best level. It depends on how many drives you have, how big they are and whether you care more about space, safety or speed.

RAID 5 vs RAID 6: which should you choose?

This is the most common decision for anyone building a multi-drive array, and the answer has changed as drives have grown larger.

RAID 5 costs you one drive of capacity and tolerates one failure. RAID 6 costs two drives and tolerates two failures. On paper RAID 5 looks more efficient, and with small drives it is a perfectly reasonable choice. The complication is the rebuild window. When a drive fails, the array runs in a degraded state until you replace the drive and the controller rebuilds it. On a large array that rebuild can take a full day or longer, and during that time you have no redundancy left.

If a second drive fails during a RAID 5 rebuild — or if the rebuild hits an unrecoverable read error on one of the surviving drives — the whole array is lost. Because larger drives take longer to rebuild and statistically present more chances for a read error, the practical rule many administrators follow is: with drives up to a few terabytes, RAID 5 is fine; with drives of roughly 8 TB and above, prefer RAID 6, or use RAID 10 if performance matters more than capacity.

Use the calculator above to compare the two side by side with your own drives, or open the RAID 5 and RAID 6 calculators.

RAID is not a backup

This is the single most important thing to understand before relying on any array. RAID protects against one specific problem: a drive failing as hardware. It does nothing against the far more common ways people actually lose data.

• Accidental deletion or overwriting a file — RAID faithfully mirrors the deletion to every drive.
• Ransomware or malware — encrypted files are written across the array just like any other change.
• Fire, flood, theft, or power surge — all drives sit in the same box.
• Controller or file-system corruption — can take down the whole array at once.

The widely recommended approach is the 3-2-1 rule: keep three copies of your data, on two different types of media, with at least one copy stored off-site. RAID can be part of your primary copy because it keeps a system running through a drive failure, but it is never a substitute for real, separate backups.

Hardware RAID, software RAID and ZFS

The same RAID levels can be implemented in radically different ways, and the choice affects performance, portability, recovery options, and total cost. There are three mainstream approaches: hardware RAID cards, operating-system software RAID, and file-system-integrated RAID such as ZFS or Btrfs. None is universally best; each has trade-offs that matter more or less depending on your use case.

Hardware RAID

A dedicated PCIe controller card manages the array entirely below the operating system. Vendors include LSI/Broadcom, Adaptec/Microchip, and Areca. The card presents the array to the OS as a single virtual disk; the OS has no idea multiple drives are involved. High-end cards include onboard cache RAM (typically 1–8 GB) protected by a battery backup unit or flash-backed cache module, which lets writes complete quickly and safely even during a power loss.

Hardware RAID historically dominated because it offloaded parity calculations from the CPU. Modern CPUs make that argument weaker — parity maths is trivial for a modern server processor — but hardware RAID still offers advantages in dedicated environments: consistent performance under load, boot-from-array capability without OS complexity, and mature management tools.

The main risks: if the controller card itself fails, you need an identical (or firmware-compatible) replacement to read the array. Drive metadata is stored in a proprietary format on the disks, so simply moving them to a different controller or a plain SATA port will not work. Keeping a cold spare of your RAID card is a legitimate expense for hardware RAID deployments in serious environments.

Software RAID (mdadm, Storage Spaces, LVM)

Software RAID runs in the operating system. Linux uses mdadm, which has been the reference standard for decades and is genuinely excellent — well-tested, portable, and openly documented. Windows offers Storage Spaces, which is more limited but integrated into the OS. Both handle standard RAID levels and can be moved between systems by moving the drives.

The portability advantage is significant. If your Linux server dies but its drives are healthy, you can install them in any other Linux machine and reassemble the array. Hardware RAID cannot do this without an identical controller.

Performance on modern hardware is essentially indistinguishable from a middling hardware RAID card. The parity calculations that used to require dedicated silicon now happen on a single CPU core at a fraction of its capacity. The historical argument that software RAID is slower simply does not hold on hardware built after roughly 2015.

The trade-off is write safety without a battery-backed cache. A sudden power loss during a write can corrupt the array in ways that hardware RAID with BBU would prevent. On a workstation, this is usually not a concern. On a critical production database, it is a reason to add a UPS or use hardware RAID with cache protection.

ZFS and Btrfs (file-system-integrated RAID)

ZFS treats storage as a unified system where the file system, volume manager, and RAID layer are all one thing. This solves problems that traditional RAID cannot: silent data corruption (bit rot) is detected and repaired transparently through checksums; snapshots are essentially free; compression and deduplication are built in.

The RAID equivalents in ZFS are RAIDZ1 (like RAID 5), RAIDZ2 (like RAID 6), and RAIDZ3 (three-drive fault tolerance, which no traditional RAID level offers). Rebuild in ZFS only rewrites actual used data, not the entire drive surface, which can dramatically reduce rebuild time on partially full arrays. A half-full 10 TB drive rebuild takes half the time.

The catch: ZFS likes RAM (the old rule of 1 GB per TB is only really needed with deduplication), ECC memory is recommended for full data integrity, and its management concepts take time to learn. Adding a single drive to an existing RAIDZ group was impossible for years; OpenZFS 2.3 (2025) added RAIDZ expansion, so check the version your system runs.

How much space do you actually need?

Capacity planning is where most home and small-business RAID builds go wrong. Either the array is undersized and needs replacing in eighteen months, or it is drastically oversized and money that could have gone into a better backup strategy sits in unused terabytes. Getting this right requires thinking about growth, not just current needs.

The rule of doubles

Data storage needs roughly double every three years for a typical user or small team. If you currently use 4 TB, expect to use 8 TB in three years and 16 TB in six. Building an array sized only for current usage guarantees a rebuild within two years. Building for 2–3x current usage is standard practice.

The exception is if your usage is dominated by a specific known-growth pattern — a security camera system recording continuously, for example, has a mathematically predictable footprint. For general-purpose storage, the doubling rule is safer than any specific calculation.

Usable capacity by scenario

Cost per usable terabyte

A common planning mistake is comparing drive prices instead of usable capacity prices. If 14 TB drives cost $260 each and 18 TB drives cost $320 each, the naive comparison says the 14 TB is cheaper. But the cost per usable TB changes based on your RAID level:

The larger array is nearly always cheaper per usable terabyte, because parity overhead is fixed regardless of drive count. Six drives lose two to parity; eight drives lose two to parity; the ratio improves with more drives. The trade-off is the initial capital cost and the operational complexity of managing more drives.

SSD vs HDD in RAID

Most RAID advice on this page was developed for mechanical hard drives. When you build a RAID array from SSDs, many of those assumptions shift. Some problems disappear, new ones appear, and the traditional recommendations do not always translate directly.

Rebuild time collapses

The biggest single change: SSD rebuild speeds are limited by the RAID controller or CPU, not the drive. A modern SATA SSD can sustain 500 MB/s writes indefinitely; NVMe drives push past 3 GB/s. A 4 TB SATA SSD can rebuild in under three hours; a 4 TB NVMe drive rebuilds in under an hour on capable hardware. The extended vulnerability window that makes RAID 5 dangerous on large HDDs largely disappears on SSDs.

This changes the RAID level calculus. RAID 5 on SSDs is genuinely reasonable up to fairly large drive sizes, because the rebuild window is short enough that a second failure during rebuild is statistically unlikely. Many SSD-based servers use RAID 5 comfortably where the equivalent HDD build would use RAID 6.

Wear leveling and correlated failure

SSDs have finite write endurance measured in terabytes written (TBW) or drive writes per day (DWPD). Drives in the same RAID array receive the same writes (adjusted for parity distribution). If you buy four SSDs from the same batch, put them in the same array, and hammer them for years, they will wear out at nearly the same time. Correlated failure risk is arguably higher for SSDs than HDDs, and the failure mode is unforgiving: SSDs often die abruptly rather than degrading gradually with warning signs.

Mitigating this is standard: buy enterprise-grade drives with high TBW ratings for arrays that see heavy writes, mix production batches when possible, and monitor SSD wear indicators through SMART attributes. Enterprise SSDs are dramatically more durable than consumer models — often 10x the TBW rating for a modest price premium in server contexts.

Write amplification and parity

RAID 5 and RAID 6 introduce a write pattern that SSDs handle less efficiently than sequential writes. Every small write requires reading the old parity, calculating the new parity, and writing both the data and the new parity. On a mechanical drive, this is a performance concern. On an SSD, the write amplification also affects endurance — parity RAID can burn through drive lifespan faster than expected on write-heavy workloads.

For write-intensive SSD arrays, RAID 10 is often the better choice: simpler write pattern, better performance, easier on drive endurance. The capacity cost is real but SSD prices have fallen enough to make it defensible.

TRIM and RAID

TRIM (the command that tells an SSD which blocks are no longer in use, allowing it to reclaim them efficiently) does not always pass through RAID controllers correctly. Older hardware RAID cards frequently block TRIM entirely, which over time degrades SSD performance and wear behavior. Modern hardware RAID cards support TRIM, but check specifications before assuming. Software RAID and ZFS handle TRIM properly on all recent versions.

What to do when a RAID array fails

Every RAID array will eventually experience a failure. Most are handled cleanly by the controller: one drive dies, an alert fires, the drive is replaced, the array rebuilds. But sometimes the situation is worse — a controller fails, multiple drives drop simultaneously, or a rebuild fails partway through. What you do in the first hours after discovering the problem often determines whether the data is recoverable.

Rule zero: stop touching the array

The single most damaging thing you can do after a serious RAID failure is continue writing to the array. Every additional write potentially overwrites data that might otherwise be recoverable. If the array is producing errors, unmount it, power it down cleanly, and stop.

This is especially critical if you are considering data recovery services. Professional recovery firms work by cloning the failed drives block-by-block, then reconstructing the array on those clones. Every write you performed after the initial failure reduces what they can recover. If the data is important, the correct sequence is: power off, take photos of the physical setup, and call a recovery service before doing anything else.

Common failure scenarios and responses

Data recovery services

Professional recovery for RAID arrays costs anywhere from $500 for straightforward single-drive recoveries to $10,000+ for complex multi-drive failures with mechanical damage. The pricing is not arbitrary — these companies operate cleanroom facilities, maintain libraries of drive firmware for repairs, and employ engineers who reverse-engineer proprietary RAID metadata formats. If the data is valuable, they earn the fee. If the data can be recreated from backup or is not worth four figures, do not use them.

Get quotes in writing before authorizing work, insist on a "no data, no charge" policy (standard in the industry), and verify that the recovery service can return data on media of your choice. Reputable firms are transparent about success probability; anyone promising guaranteed recovery is not being honest with you.

Common RAID mistakes

• Treating RAID as a backup. It is worth repeating because it causes the most data loss.
• Mixing drive sizes. In standard levels the array sizes every drive to the smallest one, so a 10 TB drive in an array of 8 TB drives wastes 2 TB. Plan with matching capacities.
• Using desktop drives in a 24/7 array. Continuous workloads need drives rated for it; consumer desktop drives wear out faster and can drop out of arrays.
• Ignoring drive health. Enable SMART monitoring and email alerts so you replace a failing drive before a second one goes.
• No UPS. A power cut mid-write can corrupt an array. An uninterruptible power supply is cheap insurance.
• Never testing recovery. Know how your rebuild process works before you need it, and keep a spare drive on hand.

Why Windows shows less than the drive label

Drive makers count 1 TB as 1,000,000,000,000 bytes. Windows counts in binary units, where 1 TiB is 1,099,511,627,776 bytes, but still writes "TB". Nothing is missing: an 8 TB drive shows up as 7.28 TB in Windows, and 72 TB of usable RAID space shows up as 65.5 TB.

The calculator shows both. Switch to TiB under Advanced settings if you want every figure the way your operating system shows it.

Questions