Hard drives fail. It is a statistical certainty, not a remote possibility. According to Backblaze's annual reports, the average annualised failure rate for drives in production environments ranges between 1% and 3%, and that figure increases significantly after the third year of use. In a server with four drives operating for five years, the probability of experiencing at least one drive failure is statistically high. If data resides on a single unprotected drive, a failure means total loss.
RAID (Redundant Array of Independent Disks) is the technology that has been solving this problem for decades. It combines multiple physical drives into a single logical unit to provide redundancy, performance or both, depending on the RAID level configured. It is the first line of defence against data loss from hardware failure and an essential component of any production server.
In this guide we explain each RAID level, its advantages and limitations, when to use each one, the differences between hardware and software RAID, and why RAID should never be confused with a backup. If you manage dedicated servers or your own infrastructure, this article will give you the fundamentals to make informed decisions about your data storage.
What Is RAID
RAID was conceptualised in 1988 by David Patterson, Garth Gibson and Randy Katz at the University of California, Berkeley, in their paper "A Case for Redundant Arrays of Inexpensive Disks". The original idea was simple but revolutionary: combine inexpensive drives to achieve performance and reliability superior to that of a single high-end drive.
The fundamental principle of RAID is to distribute data across several physical drives so that the array offers advantages that a single drive cannot provide. Depending on the RAID level chosen, the priority is performance (read and write speed), redundancy (tolerance to drive failures) or a balance between both. The term "Independent" replaced the original "Inexpensive" over the years, reflecting that RAID is now applied to any type of drive, from budget HDDs to enterprise SSDs and NVMe drives.
RAID 0: Striping without Redundancy
RAID 0 distributes data in alternating blocks (stripes) across two or more drives. Data is spread evenly: block 1 goes to drive A, block 2 to drive B, block 3 to drive A, and so on. This allows read and write operations to execute in parallel across multiple drives, multiplying throughput.
The total capacity is the sum of all drives (2 drives of 1 TB = 2 TB usable). Performance scales linearly with the number of drives. However, RAID 0 offers no redundancy whatsoever: if a single drive fails, all data in the array is lost. In fact, the probability of array failure increases with each drive added, since a single failure is enough to lose everything.
When to use RAID 0: exclusively in environments where performance is critical and data is disposable or backed up elsewhere. Typical examples: rendering cache, temporary processing spaces, development environments where data can be regenerated. Never in production without external backup.
RAID 1: Mirroring
RAID 1 creates an identical copy (mirror) of the data on two or more drives. Each write is performed simultaneously on all drives in the mirror. If a drive fails, the other contains a complete copy of all data and the system continues operating without interruption.
The usable capacity is that of a single drive (2 drives of 1 TB = 1 TB usable), since the second drive stores an exact replica. Reads can benefit from both drives in parallel, improving read performance. Writes do not improve in speed because each operation must complete on all drives.
When to use RAID 1: ideal for operating system drives, boot partitions and servers with few drives (2 bays). It is the simplest and most reliable configuration to ensure that a drive failure does not stop the server. Very common in SME dedicated servers with 2 drives for the operating system.
RAID 5: Striping with Distributed Parity
RAID 5 combines striping with distributed parity. Data is spread in blocks across all drives in the array, and a parity block is also calculated and distributed in rotation among all drives. This parity allows the data from any failed drive to be rebuilt.
It requires a minimum of 3 drives. The usable capacity is (N-1) drives, where N is the total number. With 4 drives of 1 TB, the usable capacity is 3 TB. RAID 5 tolerates the failure of a single drive. If a second drive fails during reconstruction, all data is lost.
Read performance is excellent thanks to striping. Writes are slower than RAID 0 or RAID 10 because each write requires calculating and writing parity (write penalty). On large-capacity HDD drives, reconstruction after a failure can take hours or even days, during which the array operates in degraded mode with a higher risk of a second failure.
When to use RAID 5: a good option for general storage with a balance between capacity and redundancy. Arrays of 3 to 5 drives with predominantly read workloads. Not recommended for large arrays with high-capacity HDD drives due to the risk during reconstruction.
RAID 6: Double Parity
RAID 6 is an evolution of RAID 5 that adds a second parity block, also distributed across all drives. This allows the simultaneous failure of two drives to be tolerated without losing data, which drastically reduces the risk during reconstruction.
It requires a minimum of 4 drives. The usable capacity is (N-2) drives. With 6 drives of 2 TB, the usable capacity is 8 TB. The write penalty is higher than RAID 5 because each write must calculate two parity blocks. However, the additional safety more than compensates for this disadvantage in production environments.
When to use RAID 6: recommended for large arrays (6 or more drives) and especially with high-capacity HDD drives (4 TB or more) where RAID 5 reconstruction would take too long. It is the standard configuration in storage servers that prioritise data protection over write performance.
RAID 10: Mirror + Stripe
RAID 10 (also written as RAID 1+0) combines mirroring and striping. It first creates pairs of mirrored drives (RAID 1), then distributes data in stripes across those pairs (RAID 0). This simultaneously provides the redundancy of mirroring and the performance of striping.
It requires a minimum of 4 drives (always an even number). The usable capacity is 50% of the total (4 drives of 1 TB = 2 TB usable). It tolerates the failure of one drive per mirror pair. In the best case it can tolerate up to N/2 simultaneous failures (one per pair). Reconstruction is fast because it only requires copying data from one drive to another within the pair, without the need to calculate parity.
When to use RAID 10: the best option for workloads with high IOPS and write-intensive operations. Databases (MySQL, PostgreSQL, MongoDB), mail servers, virtual machines. It is the configuration EasyDataHost recommends for data drives in enterprise servers where performance and reliability are critical.
RAID 50 and RAID 60: Nested Levels for Enterprise
RAID 50 (RAID 5+0) combines two or more RAID 5 arrays in a RAID 0 stripe. This improves write performance compared to a simple RAID 5 and tolerates the failure of one drive per RAID 5 sub-array. It requires a minimum of 6 drives (two groups of 3). It is common in enterprise storage servers that need large capacity with better performance than pure RAID 5.
RAID 60 (RAID 6+0) applies the same principle with RAID 6 sub-arrays instead of RAID 5. It tolerates up to 2 drive failures per sub-array, providing maximum protection for large arrays. It requires a minimum of 8 drives (two groups of 4). It is the most robust configuration for environments where data loss is unacceptable and arrays of 12, 24 or more drives are managed.
RAID Levels Comparison Table
The following table summarises the key characteristics of each RAID level to facilitate choosing the right one for your use case:
| Level | Min. drives | Usable capacity | Fault tolerance | Performance | Use case |
|---|---|---|---|---|---|
| RAID 0 | 2 | 100% (N drives) | None | Maximum read/write | Cache, temporary data |
| RAID 1 | 2 | 50% (1 drive) | 1 drive | Good read, normal write | OS, boot, 2-drive servers |
| RAID 5 | 3 | (N-1) drives | 1 drive | Good read, penalised write | General storage, file servers |
| RAID 6 | 4 | (N-2) drives | 2 drives | Good read, higher write penalty | Large arrays, high-capacity HDDs |
| RAID 10 | 4 | 50% (N/2 drives) | 1 per mirror pair | Excellent read/write | Databases, high IOPS |
| RAID 50 | 6 | (N - sub-arrays) drives | 1 per sub-array | Better than pure RAID 5 | Enterprise storage, large capacity |
| RAID 60 | 8 | (N - 2*sub-arrays) drives | 2 per sub-array | Better than pure RAID 6 | Maximum protection, 12+ drive arrays |
Hardware RAID vs Software RAID
RAID implementation can be carried out via a dedicated hardware controller or directly in software at the operating system level. Each approach has clear advantages and disadvantages:
- developer_board Hardware RAID (controllers): dedicated cards such as LSI MegaRAID, Broadcom, Dell PERC or HPE Smart Array that manage the array independently of the operating system. They include battery-backed cache (BBU/FBWC) that accelerates writes and protects cached data during power outages. They are the standard option in Dell, HPE and Supermicro servers. The main advantage is performance and transparency for the OS; the disadvantage is cost and vendor dependency.
- terminal Software RAID (mdadm): the native Linux RAID implementation. It requires no additional hardware, is free and allows managing RAID 0, 1, 5, 6 and 10 arrays directly from the kernel. mdadm is extremely stable and has proven its reliability over decades. The disadvantage is that it consumes server CPU for parity calculations (negligible on modern CPUs) and lacks battery-backed cache.
- settings_suggest ZFS: a file system and volume manager that implements its own version of RAID (RAIDZ1, RAIDZ2, RAIDZ3 and mirror). ZFS integrates RAID, file system, snapshots, compression and integrity verification (checksums) into a single layer. It automatically detects and repairs silent data corruption (bit-rot) that conventional RAID cannot detect. It is the most advanced option for storage servers where data integrity is the top priority.
- hub Ceph: distributed storage that goes beyond local RAID. Instead of protecting data within a single server, Ceph replicates it across multiple servers, eliminating the server as a single point of failure. It is the foundation of EasyDataHost's Cloud IaaS.
Practical recommendation:
For dedicated servers with an included hardware controller, use the manufacturer's RAID controller. For servers where you want maximum flexibility and control, mdadm or ZFS are excellent options. For cloud infrastructure with high availability across nodes, Ceph is the reference solution.
RAID Is Not Backup
This is the most common and dangerous mistake made with RAID: assuming that having drives in RAID is equivalent to having a backup of the data. RAID protects against the physical failure of drives, but it does not protect against any of the following situations:
-
warning
Accidental deletion: if an administrator runs
rm -rfon important data, RAID reflects the deletion instantly across all drives. - warning Ransomware and malware: an encryption attack affects data on all drives in the array simultaneously.
- warning Logical corruption: application errors, corrupt databases or failed updates propagate to all drives.
- warning RAID controller failure: a defective controller can corrupt the entire array.
- warning Physical disasters: fires, floods or theft affect all drives in the server equally.
RAID is an availability tool (keeping the server running when a drive fails), not a data protection tool against all possible scenarios. For real protection you need an external backup system with versioning and, preferably, an offsite copy. We have explored this concept in depth in our article A snapshot is not a backup.
EasyDataHost Recommendations
At EasyDataHost we configure the RAID level on each server based on the workload, the number of available drives and the client's performance and protection requirements. These are our general recommendations:
- check_circle Servers with 2 drives: RAID 1 for the operating system and data. Simple, reliable, no complications. Standard configuration in our SME servers and outlet servers.
- check_circle Servers with 4+ drives for databases: RAID 10 for maximum IOPS performance and fast reconstruction. The configuration we recommend for enterprise servers with database workloads.
- check_circle Bulk storage servers: RAID 6 or RAID 60 to maximise usable capacity with double fault tolerance. Ideal for storage servers with 8 or more high-capacity HDDs.
- check_circle Cloud IaaS: our cloud goes beyond local RAID: it uses Ceph with triple NVMe replication across servers, eliminating any single point of failure at the drive, server or rack level.
Regardless of the RAID level, all our servers support HDD, SSD and NVMe drives. You can learn about the differences between these storage types in our article Storage: HDD vs SSD vs NVMe.
Conclusion
RAID remains a fundamental component of any production server. Choosing the right level can mean the difference between a transparent drive failure that goes unnoticed and a catastrophic data loss that stops the business. The key is to understand what each level offers and select the one that best suits your workload.
- arrow_right RAID 1 is the simplest and most reliable option for 2 drives: ideal for operating system and boot.
- arrow_right RAID 5/6 balances capacity and redundancy: always RAID 6 when the array has 4 or more drives.
- arrow_right RAID 10 delivers the best performance with redundancy: the choice for databases and high IOPS.
- arrow_right Hardware vs Software RAID: both are valid. ZFS adds data integrity; Ceph adds distribution across nodes.
- arrow_right RAID is not backup: it protects against drive failures, not against deletions, ransomware or disasters.
If you need help choosing the right RAID configuration for your dedicated server, contact our team. We configure the RAID, the operating system and the monitoring so that your server is protected from day one.