RAID and the server disk subsystem: levels, controllers, mistakes

In short. The RAID level is chosen by drive size and workload, not by taste. Databases and 1C want RAID 10; archives and large drives want RAID 6; big arrays want RAID 60. Do not build RAID 5 on drives of 4 TB and up: rebuilding a single 16 TB drive takes around 49 hours, and the array has no redundancy for all of it. RAID 4 is no longer used — its dedicated parity drive becomes the write bottleneck. And above all: RAID protects against a drive failure and nothing else — backup is a separate job.

Drives and RAID controllers with prices → — selected by capacity, interface and cost per terabyte.

Jump to: RAID levels · RAID 4 versus RAID 5 · how many drives you can lose · why RAID 5 on large drives is dangerous · usable capacity arithmetic · RAID is not a backup · controller: RAID or HBA · cache and power protection · SSD, NVMe, HDD · the spare drive · catalogue prices · questions and answers

The disk subsystem is the most common bottleneck in a server and, at the same time, the place where a configuration mistake costs data rather than speed. Here are the RAID levels, the arithmetic of capacity and rebuild, the choice of controller and the usual misconceptions.

RAID levels: what to use and when

A simple rule: if the workload is small-block writes (a database, 1C, a mail server), take RAID 10 and do not economise on drives. If the workload is sequential reads and bulk storage, take RAID 6 and economise on drive count.

RAID 4 versus RAID 5: why level 4 is missing from configurators

There is exactly one difference — where parity lives. RAID 4 dedicates a whole drive to it; RAID 5 distributes parity blocks across every drive in the array.

The consequence is fundamental. Every write to a RAID updates both data and parity. In RAID 4 each write, wherever it lands, must update the same parity drive — which instantly becomes the bottleneck: the other drives idle and the array performs like a single disk. In RAID 5 parity is spread out, the load is shared, and the array writes faster with the same redundancy and the same usable capacity.

That is why server controllers do not offer RAID 4: for identical capacity loss it is slower. The one place the dedicated-parity scheme survives is specialised file systems such as NetApp's WAFL, where the weakness is offset by write journalling and non-volatile memory. On a server with a Smart Array or a PERC the choice between 4 and 5 does not arise: you take 5, and on large drives you take 6.

Fault tolerance in numbers: how many drives you can lose

• RAID 5 — any one drive. A second failure before the rebuild completes means the whole array is gone.
• RAID 6 — any two drives. This is a different class of protection: the array survives a second failure exactly when it is most likely, during the rebuild of the first.
• RAID 10 — one drive in each mirrored pair. An eight-drive array can lose up to four drives if they come from different pairs; two drives from one pair kill it. "Survives four failures" is a lottery, not a guarantee.
• RAID 50 — one drive per RAID 5 group. Two groups of four survive two failures in different groups and do not survive two in one.
• RAID 60 — two drives per group. The most resilient layout for arrays of dozens of large drives.

The practical point of RAID 50 and 60 is not tolerance as such but rebuild time: only the affected group is recalculated, not the whole array. On twenty drives that is the difference between a day and a week in a degraded state.

Why RAID 5 on large drives is a bad idea

When a drive fails the array starts rebuilding onto a spare, and that is not instant. A 16 TB drive at a realistic rebuild rate of about 90 MB/s under production load takes roughly 49 hours — nearly two days during which the array carries no redundancy at all.

The worse part is the reading. To rebuild one drive the controller must read all the others in full: in an array of 8 drives of 16 TB that is 112 TB of continuous reads. Enterprise SAS drives are rated for one unrecoverable read error per 10¹⁵ bits, roughly one per 125 TB read. Consumer-class SATA drives are an order of magnitude worse — one per 10¹⁴ bits, about 12.5 TB. Put that against the 112 TB that has to be read and it is clear that on SATA a RAID 5 rebuild at this scale will almost certainly hit a read error, which means losing either the array or part of the data.

Add that drives in a server usually come from one batch with identical run hours: if one failed from wear, the rest are at the same threshold. Hence RAID 6 for high-capacity drives — the second parity drive is cheaper than data recovery.

Usable capacity arithmetic

Taking 8 × WD Ultrastar DC HC550 16 TB SAS at 5 031 764 UZS each — 40 254 112 UZS for the set:

• RAID 6 — 96 TB usable. Two drives go to parity; two failures are survivable. The working choice for a file store or a backup target.
• RAID 10 — 64 TB usable. Half the capacity goes to mirrors, but writes are several times faster and a rebuild takes hours rather than days: one drive is copied instead of the whole array being recalculated.
• RAID 5 — nominally 112 TB, that is 16 TB more than RAID 6. Those 16 TB are exactly the price of the risk above, which is why nobody builds it on drives this size.

And "usable" here is pre-format capacity. The file system, snapshots and metadata take a few more per cent, and you cannot fill an array to the brim: above 80–85 % performance drops and rebuilds get harder. Plan with headroom.

RAID is not a backup

The misconception that keeps costing data. RAID protects against a physical drive failure and nothing else. It will not save you from:

• a user deleting files or an administrator's mistake;
• ransomware — the data is neatly encrypted across every drive of the array at once;
• file system or database corruption;
• a controller failure, a fire, a stolen server.

A backup must live outside this server, and at least one copy must be unreachable from the production network so it is not encrypted along with the original.

The controller: RAID or HBA

• RAID mode — the controller assembles the array and presents one volume to the operating system. The classic case for a standalone server: Dell PERC H730 (5 750 588 UZS), HPE Smart Array MR416i-a (8 625 882 UZS).
• HBA mode (pass-through) — the controller hands the drives to the system directly. Required by software-defined storage and hyperconverged clusters that manage redundancy themselves: Ceph, vSAN, Storage Spaces Direct, ZFS. Hardware RAID underneath them is not merely unnecessary but harmful — it hides drive health from the system. Use an HPE Smart Array E208i-a (5 750 588 UZS) or a Dell PERC H345 (4 312 941 UZS).

Decide on the mode before ordering: not every controller is equally good at both. Model numbering is decoded in our PERC and Smart Array reference.

Drive count is a separate matter. An eight-lane controller addresses eight drives directly; to connect twenty-four you need a backplane with an expander or a separate expander card (7 188 235 UZS).

Cache and power protection

Controllers with write cache deliver a substantial performance gain but require a battery or a supercapacitor. Without cache power protection a power cut means losing whatever was in the cache at that moment, very likely corrupting a database.

This is also the cause of the most common "unexplained" slowdown: after three or four years the battery loses capacity, the controller switches the cache to write-through on its own, and the server becomes several times slower. There is not a single error in the log — only a note about the cache power module. If a server "suddenly got slow" and nothing was changed, check the battery first.

SSD, NVMe, HDD — what goes where

• NVMe — databases, busy applications, the cache tier of a storage system: Micron 7400 Pro 1.92 TB U.3 — 4 312 941 UZS.
• SAS/SATA SSD — virtualisation, general-purpose workloads, system volumes: Intel D3-S4520 7.68 TB — 10 782 352 UZS.
• HDD — archives, backups, high-capacity low-activity file stores. Cost per terabyte still decides here: the WD Ultrastar 22 TB SAS at 8 625 882 UZS is far cheaper per terabyte than any SSD.

Do not mix drives of different type, capacity or spindle speed in one array: the controller levels the whole array down to the worst drive. Give the operating system and the hypervisor their own pair — a boot device such as the HPE NS204i-p (10 063 529 UZS) or a Dell BOSS (7 907 058 UZS) — so they do not consume array bays.

The spare drive

A replacement drive has to be on site before the failure, not ordered after it.

• Hot spare. The drive sits in the cage, spinning and waiting. On failure the rebuild starts automatically with no human involved — on a remote site this is the only sensible option.
• Global spare. One spare serves several arrays on the same controller. It saves a bay, but with many arrays the risk of two failures against one spare is real.
• Cold spare. The drive sits on a shelf. Cheaper, but the rebuild only starts once somebody drives over and inserts it — another day without redundancy for a server in another city.

Buy the spare in the same model and capacity as the array drives. A larger drive will work but the extra capacity is wasted; a smaller one the controller will simply refuse.

Controllers and drives in the catalogue

Checklist before building the array

• Workload type: small-block writes mean RAID 10; sequential reads and bulk storage mean RAID 6.
• Single drive capacity: from 4 TB upwards RAID 5 is off the table.
• Whether a spare is on site, and whether it is hot or cold.
• The state of the controller battery or supercapacitor, especially on a server older than three years.
• Controller mode: RAID or HBA — software-defined storage needs the latter.
• A separate volume for the operating system so the hypervisor does not occupy array bays.
• Where the backup goes, how often, and whether a restore has ever been tested.
• Fill level: plan for no more than 80 % of usable capacity.

We will size the disk subsystem for the job: usable capacity, RAID level, a controller with the right cache and drives with the right headroom. Get in touch; drives and controllers with prices are here.

Questions and answers

How does RAID 4 differ from RAID 5?

By where parity sits. RAID 4 keeps it entirely on one dedicated drive; RAID 5 distributes it across every drive in the array. Usable capacity and fault tolerance are identical — one drive — but in RAID 4 the parity drive is updated on every write and becomes the bottleneck, which is why RAID 5 is what actually gets used.

What is RAID 5 in plain terms?

An array of three or more drives in which data is spread across all of them together with checksums that allow the contents of any one failed drive to be reconstructed. Usable capacity equals the total minus one drive. The price of that economy is a long rebuild and total loss of the array if a second drive fails before it finishes.

How fault tolerant is RAID 50?

RAID 50 stripes across several RAID 5 groups. Each group can lose one drive; two failures in different groups are survivable, two in the same group are not. The main gain is not tolerance but rebuild time — only one group is recalculated, cutting the degraded window several times over compared with a wide RAID 5.

How many drives does RAID 6 need?

Four at minimum, six as a sensible minimum. On four drives half the capacity goes to parity, and RAID 10 gives a better capacity-to-speed ratio. RAID 6 starts to make sense from six drives up, where the parity overhead shrinks.

Which stripe size should I choose?

The controller default, usually 64–256 KB, suits most workloads. A smaller stripe favours databases with small random operations, a larger one favours streaming video and archives. Change it only against a measured problem: the stripe size cannot be altered after the array is created without rebuilding it.

Can I put drives of different capacity in one array?

Technically yes, but the controller uses the capacity of the smallest drive from each — the difference is lost. Mixing spindle speeds or drive types (SSD and HDD) in one array is a bad idea: performance levels down to the worst member.