Avoid stacking multiple smart layers (RAID-on-RAID, LVM, extra caching). Pick one layer to own redundancy to keep failures and recovery predictable.
This guide settles the RAID 1 vs. RAID 5 question, along with the rest of the matrix.
If you're still mapping out the different RAID levels, start with our breakdown of how RAID works. This article assumes you already know the difference between a stripe and a mirror and want to make a decision.
Before picking one, it helps to know what the different RAID levels actually do in production.
Six or seven RAID levels exist on paper. In production hosting, the field narrows to four: 1, 5, 6, and 10. Nested arrays like 50 and 60 show up on large storage arrays, but for a web server, they're overkill — if you're reaching for RAID 60, you're building a SAN.
A single logical write to RAID 5 isn't one disk operation — the controller reads the old data block, reads the old parity, computes new parity, then writes both. That's four I/O operations for one write. RAID 6 makes that six. RAID 10 just mirrors the write, so it's effectively one. That gap is the entire reason database admins reach for RAID 10 and shrug at the lost capacity.
RAID 1 mirrors the data on all the drives in the RAID (typically just a pair). No matter how many drives you put into a RAID 1, you get the usable space of a single drive and read performance that scales because requests can be answered from either disk. If one drive fails, the other keeps things running until you replace the failure.
This is the correct default for an OS partition and for small sites. It's boring, it's cheap, it's predictable, and predictable is exactly what you want from the layer holding your data. On NVMe, software RAID 1 via Linux mdadm is fast enough that the mirror is never your bottleneck. Your PHP workers or your database will tap out long before the disk subsystem does.
RAID 5 stripes data across all disks and sprinkles parity blocks among them, so you only sacrifice one disk's worth of capacity regardless of array size. On a spec sheet, it looks like the smart middle ground: redundancy with minimal capacity loss.
With one drive gone, your array has zero redundancy until the rebuild finishes, and rebuilding forces the controller to read every remaining disk in full to reconstruct the missing data. On modern multi-terabyte drives, that read can run for many hours, hammering disks that are already the same age and the same wear level as the one that just failed. If a second disk throws an unrecoverable read error during that window, the whole array is gone.
There's a fair counterpoint: a well-run array with regular scrubbing and real disk monitoring catches bad sectors before they bite, and plenty of RAID 5 horror stories are really stories about nobody scrubbing the array for three years. That's true. But "RAID 5 is fine if you operate it perfectly" is a weak foundation for a hosting workload, and RAID 6 removes the gamble entirely for the price of one more disk. Which brings us to…
RAID 6 is RAID 5 that learned from its mistakes. Two independent parity blocks per stripe means you can lose two disks at once and still rebuild — including the nightmare case where a second disk fails while the first is still rebuilding. You give up two disks' worth of capacity instead of one, and the write penalty is higher (six I/O per write versus four). In exchange, the rebuild gamble disappears.
For large, capacity-oriented arrays — archives, backups, media, or anything where you want maximum usable terabytes with real fault tolerance and you're not write-bound — RAID 6 is the sane choice. With a good controller and enough cache, write performance is better than the raw I/O math suggests, because writes get coalesced before they hit disk. Below four or five disks, though, RAID 6 stops making sense; the parity overhead eats too much, and you're better off mirroring.
RAID 10 is a stripe across mirrored pairs. You get the read and write performance of striping with the clean redundancy of mirroring, and the rebuild is trivial: to recover a failed disk, the array copies data from its surviving mirror partner. A RAID 10 rebuild touches one disk, not all of them.
The cost is brutal and honest: you lose half your raw capacity. Eight disks of 2 TB give you 8 TB usable, not 14. For write-heavy workloads — databases, busy eCommerce, anything committing transactions constantly — that's a cost worth paying, and it's why RAID 10 is the default answer for database storage. Slower disks in RAID 10 frequently beat faster, more expensive disks in RAID 5 because the array structure matters more than the spindle speed.
These are the nested RAID levels you'll see on big storage arrays. For a single web server, you'll basically never need them, fully covering the different types of RAID systems from the ground up.
These exist to solve a scaling problem, not a hosting one.
All three are storage-array territory. For a single web server, you'll never reach for them. If you're sizing a multi-group parity array, you're building a SAN, and that's a different article.
On is*hosting dedicated servers, RAID is a choice you make at order time, not a mystery that's decided for you. On a dedicated server with four enterprise SSDs and your choice of software or hardware RAID, the configurator lets you pick Software RAID at no extra cost, or a hardware RAID controller (PERC H730) as a paid option. Four drives mean RAID 6 and RAID 10 are both on the table, not just mirroring.
Which way to go follows everything above.
If you're unsure whether software or hardware fits your workload, we compared the two in detail here.
And because RAID isn't a backup, every is*hosting plan includes free weekly backups out of the box — so the "recover from my own mistakes" half of the equation is covered before you even think about it.
Choose RAID at order: enterprise SSDs, software or hardware RAID, and free weekly backups on every plan.
One last piece of advice that's saved more arrays than any RAID level: pick one layer to own redundancy. Stacking RAID on top of LVM on top of extra caching layers feels thorough, but it makes failures and recovery unpredictable.
Before debating RAID 5 vs. 6 vs. 10, measure your actual workload (average IOPS and latency). Otherwise, you're choosing a RAID level blindly.
# Disk I/O profile: load, read/write IOPS, latency
iostat -x 5 3
# Look at r/s, w/s (IOPS) and r_await, w_await (latency, ms)
# Measure random writes using a synthetic test close to the database load
fio --name=randwrite --ioengine=libaio --rw=randwrite \
--bs=4k --numjobs=4 --iodepth=32 --size=4G --direct=1 --runtime=60People sometimes frame it as RAID 0 vs. RAID 1, but that's a false choice for hosting: RAID 0 has no redundancy at all, so a single disk failure takes everything. RAID 0 vs. RAID 1 only matters if you don't care about the data.
|
Level |
Min disks |
Usable capacity |
Disks it survives |
Write penalty |
|
RAID 1 |
2 |
50% (one disk) |
1 |
None |
|
RAID 5 |
3 |
(N−1) disks |
1 |
Heavy (4 I/O per write) |
|
RAID 6 |
4 |
(N−2) disks |
2 |
Heavier (6 I/O per write) |
|
RAID 10 |
4 |
50% |
1 per mirror |
Low |
The RAID 1 vs. RAID 5 question usually comes down to how many disks you have and what you value. RAID 1 needs only two disks and carries no write penalty; RAID 5 needs at least three and pays four I/O operations per write.
For a small site, RAID 1 vs. RAID 5 isn't really a contest. RAID 1 is simpler, faster on writes, and rebuilds without reading the whole array. RAID 5 only starts to look attractive when you have several disks and want more usable capacity than mirroring allows. However, as the sections below show, that's usually where RAID 6 or RAID 10 should win the RAID 1 vs. RAID 5 debate instead.
RAID 1 is two disks; RAID 10 is several mirrored pairs striped together. If your project fits on a single mirror, RAID 1 is plenty — on NVMe, it'll be fast enough that going to RAID 10 buys you throughput you won't use.
Reach for RAID 10 when one mirror can't hold your data, or when your write volume genuinely needs the striping. For most small-to-mid sites, RAID 1 wins on simplicity.
It's worth grounding this in a real upgrade question, because it comes up constantly.
A setup running Nginx/PHP-FPM/MariaDB on four SSDs in hardware RAID 10, sitting at a 7-day load average around 16 with peaks near 28, is looking at a move to NVMe with software RAID.
The instinct is "more disks in RAID 10 = faster." But identical NVMe drives in RAID 10 only buy you up to ~2× over RAID 1 if you're not already bottlenecked on CPU or the drives themselves, and on a web/PHP workload, you usually hit one of those ceilings first.
On NVMe, RAID 1 is frequently fast enough that the extra two drives go to redundancy, not measurable speed.
The RAID 5 vs. RAID 6 choice is the easiest one here. There's almost no modern scenario where RAID 5 beats RAID 6.
The effective replacement for RAID 5 is RAID 6 — it closes the rebuild-failure hole that makes RAID 5 dangerous on large disks, at the cost of one disk's worth of capacity and a bit more write overhead. If you were going to run RAID 5 on four or more sizable disks, run RAID 6 instead.
The only place RAID 5 still has a narrow argument is a small three-disk array where you can't spare the capacity for double parity, and even then, think hard.
The RAID 5 vs. RAID 10 decision is about priorities. RAID 5 optimizes for usable capacity; RAID 10 optimizes for write performance and rebuild safety.
For a database or a busy transactional site, it isn't close — RAID 10 every time. The IOPS gap is stark and worth putting numbers on.
Take a 12-disk array of 10K drives at roughly 300 write IOPS each: in RAID 10, you'd see on the order of 1,800 array write IOPS, against ~900 for RAID 5 and ~600 for RAID 6.
Slice that across, say, 15 VMs, and you're looking at roughly 120 / 60 / 40 IOPS per VM for RAID 10 / 5 / 6. And that's before you account for the higher write latency that parity adds.
The exact figures move with your hardware, but the ratio is the point: parity costs you writes, and a write-heavy workload feels it. Add the rebuild risk on large RAID 5 disks, and the decision is usually made before performance even enters the chat — the only thing holding people on RAID 5 is not wanting to pay RAID 10's capacity tax.
RAID 10 gives you better random read performance (any block lives on two disks, so the array picks the faster path) and dead-simple rebuilds.
RAID 6 gives you more usable capacity and survives any two simultaneous failures, not just any two from different mirrors.
Uncached RAID 6 write is genuinely awful — to write one block, the controller reads the target block plus both parity blocks, recomputes parity, and writes three blocks back: six operations for one logical write. But a controller with a decent cache can defer and coalesce writes, and the arithmetic flips.
Picture 10 disks: as an 8+2 RAID 6 array, writing a full 8-block stripe costs 10 disk writes (8 data + 2 parity). The same data on a 5-mirror RAID 10 costs 16 writes, because every block is mirrored. With enough cache to batch writes into full stripes, RAID 6 can actually hit the disks less often than RAID 10.
The real answer depends on your controller, your cache, and your write pattern — which is the kind of "it depends" that's actually true rather than a dodge.
Workload decides. Here's how the three real-world hosting profiles break down.
A typical small site is read-dominated: static assets, cached PHP output, and a modest database doing far more SELECTs than writes. You don't need parity math or four disks for this. Software RAID 1 on two NVMe drives, managed by Linux mdadm with ext4 or XFS, is the right tool.
Mirroring on NVMe gives you excellent parallel read throughput — concurrent requests get spread across both disks — and mdadm costs almost no RAM, leaving your memory free for what actually moves the needle: Nginx/Varnish cache and your database working set.
Set up in three steps:
# Create a RAID 1 mirror using two NVMe drives
mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/nvme0n1 /dev/nvme1n1
# Verify that the array is being assembled and is intact
mdadm --detail /dev/md0
# State : clean, resyncing
# Active Devices : 2
# Save the configuration so that the array is loaded at startup
mdadm --detail --scan >> /etc/mdadm/mdadm.confA busy store is the opposite profile: a dense stream of writes (cart updates, order commits, session writes, inventory changes) landing constantly, often during the exact traffic spike when you can least afford slow I/O. This is RAID 10 territory.
Beyond raw write performance, RAID 10 on SSDs sidesteps a problem that quietly shortens drive life in parity arrays: write amplification. RAID 5 and 6 constantly recompute and rewrite parity blocks, and on flash, that extra write traffic eats into the endurance rating of every drive in the array. RAID 10 has no parity to maintain. It just mirrors, so it's gentler on SSD lifespan while delivering the write throughput a transactional site needs. You pay in capacity; you get it back in performance and drive longevity.
Databases are the most latency-sensitive thing you'll put on disk, and this is where the non-obvious gotchas live.
Migrating a database from an older server with a hardware RAID controller and battery-backed write cache onto a newer box running software RAID on faster NVMe can make I/O slower (sometimes several times slower) on transactional workloads. The reason is how synchronous writes are acknowledged.
A hardware controller in write-back mode confirms the write the instant data hits its battery-protected cache, then flushes to disk in the background.
Software RAID with no dedicated cache has to honor honest fsync calls — the transaction log gets written all the way down to the physical device before the database is told "done," and you eat the full NAND latency on every commit.
If you run software RAID under a database, use enterprise NVMe drives with power-loss protection (PLP) — onboard capacitors that let the drive safely acknowledge its internal cache without risking data on a power cut. That gives you most of the latency benefit without a separate controller. If you'd rather offload it to hardware, a controller with a battery-backed write cache does the same job in silicon.
If you run ZFS for its snapshots, inline compression, and checksumming — all genuinely useful under a database — be aware that the ZFS Intent Log (ZIL) can become a bottleneck on synchronous writes.
The standard fix is a SLOG: a dedicated, low-latency, power-loss-protected device that handles the intent log separately from the main pool.
This is the layer where "just pick RAID 10" stops being the whole answer, and your controller, cache, and drive choice start to matter as much as the RAID level itself.
Every section above is about availability — keeping the server running when a disk dies. None of it protects you from the things that actually delete data: a bad migration, rm -rf in the wrong directory, ransomware, a dropped table, a corrupted application write faithfully mirrored to every disk in the array. RAID copies your mistakes just as reliably as it copies your data.
So whatever level you choose, it sits alongside a backup strategy, never instead of one.