Quickly estimate usable storage, fault tolerance, and array recovery speed.
RAID (Redundant Array of Independent Disks) combines several physical drives into one logical unit to improve performance, add redundancy, or both. How much of your raw disk space you actually get to use, and how much is reserved for protection, depends entirely on the RAID level you choose. This calculator works out the usable capacity, the overhead lost to parity or mirroring, how many drives can fail before data is lost, and a rough estimate of how long the array takes to rebuild after a drive is replaced.
The capacity maths is straightforward once you know the rule for each level. Mirroring keeps full duplicate copies, so it trades capacity for safety. Parity-based levels reserve the equivalent of one or two drives to store recovery information, so the cost of protection stays fixed no matter how many drives you add. Striped levels with no redundancy give you everything but protect nothing.
Storage figures here use decimal terabytes (1 TB = 1,000,000 MB), the same way drive manufacturers label their products, so the numbers match what you see on a Seagate or Western Digital box. Keep in mind your operating system reports capacity in binary units, which is why a "10 TB" drive shows up as roughly 9.1 TiB once formatted.
There is no single best RAID level — the right choice depends on how much you value capacity, performance, and protection, and on how many drives you have. Below is a plain summary of where each level fits.
RAID 0 spreads data across all drives with no redundancy. You get the full combined capacity and the best raw speed, but zero fault tolerance: if a single drive fails, the entire array is lost. Use it only for scratch space, caches, or temporary workloads you can rebuild from elsewhere — never for anything you cannot afford to lose.
RAID 1 writes identical copies to two or more drives. Usable capacity equals one drive, with everything else as overhead, but the array survives the failure of all but one drive. It is simple, very safe, and ideal for small two-drive systems, boot volumes, or anyone who wants maximum safety with minimum complexity.
RAID 5 stripes data across at least three drives and dedicates the equivalent of one drive to parity. You lose one drive's worth of capacity and can survive a single drive failure. For years it has been the default balance of capacity, speed, and protection for small servers and NAS units, though large modern drives have shifted many users toward RAID 6 (see below).
RAID 6 keeps two independent parity blocks, so it survives two simultaneous drive failures. It needs at least four drives and gives up two drives' worth of capacity. The extra parity makes it slower to write than RAID 5, but on arrays built from large drives the added safety is usually worth it.
RAID 10 pairs drives into mirrors and then stripes across those pairs. Usable capacity is half the total, but you get excellent performance and fast rebuilds, since recovery only has to copy one mirror rather than recalculate parity across the whole array. It is a popular choice for databases and busy virtual-machine hosts where speed and reliability both matter.
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 drive count and size, and watch how the usable capacity and tolerance change.
Every hard drive has a tiny but non-zero chance of an unrecoverable read error (URE) — a sector it simply cannot read back. Manufacturers quote this as a rate, commonly around one error per 10^14 bits read for consumer drives. That sounds astronomically rare, and for everyday use it is. The problem appears during a parity rebuild.
To rebuild a failed drive in RAID 5, the controller must read every bit on all the remaining drives to recalculate the missing data. The larger the array, the more total data must be read flawlessly in one pass. As capacities climb into the tens of terabytes, the odds of hitting at least one URE somewhere during that read grow from negligible to meaningful. If it happens in RAID 5, the rebuild can fail.
This is the core argument behind dual-parity RAID 6 for large arrays: a single read error during rebuild is survivable because the second parity block fills the gap. It is also a strong reminder that healthy, regularly scrubbed drives and proper monitoring matter as much as the RAID level itself.
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.
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.
The same RAID levels can be implemented in different ways, and the choice affects cost, flexibility, and recovery.
A dedicated controller card manages the array independently of the operating system, often with onboard cache and a battery or flash backup to protect in-flight writes during a power loss. It performs well and offloads work from the CPU, but a failed controller can be hard to replace with an identical model, and the array may be tied to that specific hardware.
The operating system handles the array — examples include Linux mdadm, Windows Storage Spaces, and ZFS. It is flexible, costs nothing extra, and is not locked to a particular controller, so you can move drives to new hardware. Modern CPUs make the performance overhead minimal for most users.
Network-attached storage boxes from vendors like Synology and QNAP run software RAID behind a friendly interface, often with proprietary flexible options (such as Synology Hybrid RAID) that let you mix drive sizes more efficiently than standard levels. They are the easiest route for home users and small offices who want redundancy without managing it by hand.
When a drive fails in a redundant array, the surviving drives keep serving data while a replacement is installed and reconstructed. The rebuild process sounds simple in theory: read every remaining block, recalculate the missing data, write it to the new drive. In practice, it is one of the most stressful periods your array will ever face, and understanding what happens during it is the difference between a smooth recovery and a catastrophic data loss.
A rebuild copies (or recalculates) the full capacity of one drive. If the controller sustains 100 MB/s during the operation, a 10 TB drive takes roughly 28 hours to complete. Double the capacity, double the time. A 20 TB drive at 100 MB/s means over two days of continuous sustained reads across every surviving disk in the array. During that window, none of the remaining drives get to rest, and any single unrecoverable read error on any of them can end the rebuild.
In real deployments, sustained rebuild speed is rarely at manufacturer peak. Array activity (users reading files, backups running, virtual machines writing to disk) competes with rebuild traffic for the same spindles. It is common to see rebuild speeds drop to 30–50 MB/s on production arrays, tripling the total time. A 20 TB rebuild on a busy array can genuinely take five or six days.
| Drive size | Time @ 150 MB/s idle | Time @ 50 MB/s busy |
|---|---|---|
| 4 TB | 7.4 hours | 22 hours |
| 8 TB | 14.8 hours | 44 hours |
| 10 TB | 18.5 hours | 55 hours |
| 14 TB | 26 hours | 77 hours |
| 18 TB | 33 hours | 100 hours |
| 22 TB | 41 hours | 122 hours |
Three things happen simultaneously during a rebuild that make failure more likely, not less:
Sustained heavy read load. Every surviving drive is read from end to end. If any of them was already on the edge of failure (marginal SMART attributes, borderline heat), the rebuild is often what pushes it over. This is why the second failure so often happens during the first rebuild.
Same age, same batch. Drives are frequently purchased at the same time from the same production batch, and they have run the same hours in the same environment. When one dies of old age, the others are statistically likely to be close behind. Rebuilding stresses them exactly when they are weakest.
URE probability accumulates over the read pass. The unrecoverable read error rate for consumer drives is typically quoted as 1 in 10^14 bits. That sounds tiny, but reading 10 TB of data means reading 8 × 10^13 bits — almost exactly the URE probability threshold. On a large RAID 5 array with several such drives, hitting one URE somewhere during the rebuild is not a rare event; it is a plausible outcome. RAID 6 survives it; RAID 5 does not.
One drive fails on a Tuesday morning. You replace it Tuesday afternoon; the rebuild starts. Estimated time at 60 MB/s sustained: about 55 hours — so the array runs in a degraded state through Wednesday, Thursday, and finishes Thursday evening.
During those 55 hours, the three surviving drives read a combined 36 TB of data. Any single URE on any of them fails the rebuild. If a second drive fails outright — also more likely because drives from the same batch tend to fail near each other — the array is lost.
This is why administrators building new large arrays in 2026 rarely choose RAID 5. The rebuild window is simply too long and too risky. RAID 6 (which survives both a URE and a second complete drive failure during rebuild) or RAID 10 (which rebuilds by copying a single mirror rather than recalculating parity across the whole array, typically in a fraction of the time) are the practical choices.
Rebuild time is not something you can eliminate, but you can shape the risk profile:
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.
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 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 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 uses substantial RAM (a rule of thumb is 1 GB per TB of storage, more if you enable deduplication), demands ECC memory for maximum data integrity, and has genuinely different management concepts that take time to learn. Expansion is also harder — you cannot easily add a single drive to an existing RAIDZ pool, though this limitation is being addressed in newer versions.
| Hardware RAID | Software RAID | ZFS | |
|---|---|---|---|
| Cost | $300–$2000+ card | Free | Free |
| Performance | Consistent, cached | Excellent on modern CPU | Excellent, RAM-bound |
| Portability | Locked to controller family | Any compatible OS | Any ZFS system |
| Bit-rot protection | No | No | Yes (checksums) |
| Learning curve | Low | Medium | High |
| Recovery on failure | Needs same card | Any Linux/Windows | Any ZFS system |
Practical recommendation: for a home NAS or small business file server, ZFS on TrueNAS or Proxmox is genuinely hard to beat. For a Windows environment, Storage Spaces is adequate. Hardware RAID makes sense in specific scenarios: boot volumes, environments where the OS must not manage the array, or where you already own a supported card.
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.
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 (see the CCTV storage calculator sites for the specific formula: cameras × bitrate × hours × retention days). For general-purpose storage, the doubling rule is safer than any specific calculation.
RAID 0: 48 TB usable, no protection. Loses all data if any drive fails. Only sensible for scratch storage where all content can be re-ripped.
RAID 5: 36 TB usable, one-drive tolerance. Fine on paper but rebuild on 12 TB drives is long enough to be genuinely risky. Not recommended for new builds at this drive size.
RAID 6: 24 TB usable, two-drive tolerance. Safer during rebuild. Good middle ground.
RAID 10: 24 TB usable, at least one-drive tolerance (often more depending on which drive fails). Faster rebuild than RAID 6. Best choice if performance matters.
For a home media library where the content is downloaded/ripped and could theoretically be reacquired, RAID 5 or even RAID 0 with good backup is defensible. For irreplaceable data (family photos, home videos), RAID 6 is the minimum sensible choice.
RAID 5: 40 TB usable but risky at this drive size and count. A second failure during rebuild has non-trivial probability. Not a serious choice for business data.
RAID 6: 32 TB usable, two-drive tolerance, safer rebuild margins. Standard business choice.
RAID 10: 24 TB usable, excellent performance, faster rebuild. Better for database-heavy workloads.
RAIDZ2 (ZFS): approximately 32 TB usable but with bit-rot detection and snapshots, which are legitimately valuable for a small business. Often the best overall choice if the team can manage ZFS.
At 18 TB drives, RAID 5 is completely off the table — a single URE during rebuild is close to a coin flip. RAID 6 gives 108 TB usable and survives dual failure. RAIDZ2 gives similar capacity with additional protections. For truly critical archives, RAIDZ3 (three parity drives) provides another layer at the cost of dropping usable capacity to 90 TB. Even RAIDZ3 does not replace off-site backup; it just extends the survival window while backups run.
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:
| Configuration | Raw cost | Usable TB | $/usable TB |
|---|---|---|---|
| 4x 14 TB in RAID 6 | $1,040 | 28 TB | $37 |
| 4x 18 TB in RAID 6 | $1,280 | 36 TB | $36 |
| 6x 14 TB in RAID 6 | $1,560 | 56 TB | $28 |
| 6x 18 TB in RAID 6 | $1,920 | 72 TB | $27 |
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.
Every RAID concept from the previous articles 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.
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.
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.
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 (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.
Bottom line for SSDs: RAID 5 becomes viable again for moderate array sizes. RAID 10 makes sense for write-heavy workloads. Enterprise-grade drives are worth the premium in production. Match your RAID level to the workload, not just to the tradition inherited from HDD arrays.
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.
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.
This is the routine case. Replace the failed drive with an identical or larger model, initiate rebuild through the controller or OS tools, and monitor SMART on the remaining drives during the rebuild. Once complete, run a scrub to verify parity consistency. Total downtime: essentially zero if the array supports online rebuild.
Usually caused by a URE on one of the surviving drives during the rebuild read pass. On RAID 5, this often means data loss on the affected stripe; some controllers continue the rebuild with corrupted blocks in that region. On RAID 6, the second parity block covers the URE and the rebuild continues successfully.
If a RAID 5 rebuild fails: stop, take an image of all surviving drives if possible, and consider whether the data is important enough to send to a professional recovery service. Do not repeat the rebuild — you will just corrupt more data.
Often not what it looks like. Frequently the underlying cause is a controller, cable, or power supply problem rather than actual drive failure. If two or more drives drop at once, immediately power everything down. Investigate power supply, cabling, and controller before assuming the drives themselves have died.
Many "catastrophic RAID failures" turn out to be a failed backplane or a bad HBA. The drives are fine; the array metadata is intact; and a proper diagnosis followed by controlled reassembly recovers everything.
The array cannot be read without a compatible replacement controller. If the failed controller is from a still-current product line, the manufacturer typically maintains firmware compatibility across the family — a newer card can often read older arrays. If the controller is discontinued, sourcing an identical replacement from eBay or a supplier is often the only option.
This is the failure mode that motivates software RAID and ZFS for critical data: no controller lock-in, and the drives can move to any compatible system.
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.
The best recovery strategy is a good backup. RAID is not backup. Recovery services exist because arrays fail in ways that no RAID level can protect against. If your data is important enough that you would pay a recovery service to get it back, it is important enough to be backed up properly in the first place, following the 3-2-1 rule described earlier.
Based on published annual failure rate (AFR) data, estimate the probability that at least one drive in your array fails within a year. This is why redundancy matters more as drive count grows.
This calculator uses the standard probability formula: if a single drive has probability p of failing within the period, the probability that none of n drives fail is (1-p)n, so the probability at least one fails is 1-(1-p)n. The probability of two or more failures follows from the binomial distribution. As drive count grows, the chance that something fails climbs quickly even though each individual drive is reliable — which is exactly the case redundancy is built for.
Answer three quick questions and get a recommended RAID level with reasoning, based on the guidance covered throughout this page.
RAIDCalc is a free, independent planning tool for system administrators, NAS owners, and IT professionals who need a fast estimate of array capacity and rebuild time. It is not affiliated with any drive, NAS, or controller manufacturer. Corrections and suggestions are always welcome.
Contact: temirowski@gmail.com
This website respects your privacy. The calculator runs entirely in your browser; the values you enter are never sent to, stored on, or processed by any server.
This site is supported by advertising. Third-party vendors, including Google, use cookies to serve ads based on a user's prior visits to this and other websites. Google's use of advertising cookies enables it and its partners to serve ads based on your visits to this site and other sites on the internet. You may opt out of personalised advertising through Google's Ads Settings, and you can review how Google handles data at policies.google.com/technologies/partner-sites.
Visitors from the European Economic Area, the United Kingdom, and Switzerland are shown a consent message before any non-essential cookies are set, in line with applicable regulations. You may withdraw or change your consent at any time.
This site may reference third-party products. We do not control the content or privacy practices of external sites and accept no responsibility for them.
Last updated: June 17, 2026.