Learn RAID - History, Background & Why You Need RAID

#Introduction

Episode 0 made sure your environment is ready. Now it's time to understand why RAID exists. Episode 1 answers three big questions: where did the RAID concept come from, what problem does it solve, and why do you — as an engineer handling storage — need it.

Many people start using RAID because of tutorials, but understanding its background is far more valuable. When you know the problems it solves, you'll find it much easier to decide which RAID level is right, when redundancy is mandatory, and how to position an array within a storage architecture.

As a note, this episode leans more toward storytelling than hands-on practice. Don't worry — starting from episode 4 you'll practice directly with mdadm commands. The conceptual understanding you bring to practice will make every command feel sensible instead of memorized. Let's start from the beginning of the story.

#The History of RAID

#The 1987 Berkeley Paper

The RAID concept was popularized by the classic paper "A Case for Redundant Arrays of Inexpensive Disks" written by David Patterson, Garth Gibson, and Randy Katz from the University of California, Berkeley in 1987. At the time, large-capacity disks were very expensive, and the authors argued that combining many cheap small disks could deliver capacity, performance, and reliability equivalent to an expensive disk.

The paper introduced RAID levels 1 through 5, each with different performance and redundancy tradeoffs. RAID level 0 was only recognized later as an informal addition for striping without redundancy. The RAID acronym itself originally meant Inexpensive Disks, which later changed to Independent when RAID was adopted by industry.

#Evolution of Levels and Implementations

Since 1987, RAID levels have kept evolving: RAID 6 for double parity, RAID 10 combining mirror and striping, RAID 50 and 60 as nested levels, all the way to dRAID introduced by ZFS for large-scale storage. On the implementation side, there are two main paths:

• Software RAID: represented by the kernel MD driver and the mdadm tool, which began around 2001 with Neil Brown and continues to evolve today.
• Hardware RAID: controller cards with battery-backed cache that handle parity on a dedicated processor.

We'll thoroughly compare these two paths in episode 3. For now, just note that these two paths have competed throughout RAID's history.

#Adoption and Modern Development

As of 2026, RAID is no longer exclusive to expensive servers. In a homelab, a Mini PC board with two SSDs can already run RAID 1 via mdadm. In the cloud, services such as EBS support RAID 0 and 10 at the instance level. On the filesystem side, ZFS brings RAIDZ and dRAID, while btrfs has built-in RAID modes — we'll cover these in episodes 8 and 22.

1987 Berkeley paper → 1990s hardware RAID → 2001 mdadm → 2026 mdadm 4.6 + OpenZFS 2.4

#The Problems RAID Solves

#Disks Fail

The core problem RAID solves is the fact that disks are components with a significant failure rate. HDDs have moving heads and platters; SSDs have flash cells with a limited number of writes. When a single disk in a system without redundancy fails, all the data on it is lost. RAID answers with three basic mechanisms:

• Redundancy: survive the failure of one or more disks.
• Performance: distribute I/O across many disks at once.
• Capacity: combine the capacity of several disks into one logical volume.

None of these three mechanisms is free — each carries overhead that we'll calculate in episode 2.

#Redundancy to Survive Failure

Say you have valuable data on a single 4TB disk. When that disk dies, the data dies with it. With RAID 1 across two disks, data is written twice — when one disk dies, the other still holds a full copy. With RAID 5 across five disks, parity is spread across all disks so one disk can fail without data loss. This level of redundancy is what distinguishes RAID levels from one another.

cat /proc/mdstat

The /proc/mdstat output shows arrays such as md0 : active raid1 sda[0] sdb[1]. If one disk fails, the state changes to degraded and the array keeps running. We'll read this file in detail in episode 5.

#Tradeoffs: Nothing Is Free

Every RAID level uses disk capacity to store redundancy data. RAID 1 uses half of the total capacity. RAID 5 uses the capacity of one disk. RAID 6 uses the capacity of two disks. The higher the redundancy, the safer the data — but the less usable capacity remains and the greater the write parity overhead.

RAID is also not a solution for every problem: it doesn't protect against accidental deletion, file corruption, or a server room fire. For exactly this reason, you'll often hear a saying that we'll repeat throughout this series — RAID is not a backup. We'll dig into the details in episode 12.

#Why You Need RAID

Let's summarize it in the context of real work. You need RAID if:

• Data must remain available when a disk fails: production databases, VMs, or a family NAS.
• I/O performance is a bottleneck: heavy read/write workloads on a single disk.
• The capacity of one disk isn't enough: you want to combine several disks into a large volume.
• You want low downtime when replacing disks: hot-swap and automatic rebuild.

Conversely, if data loss carries no major consequence or a single disk's performance is sufficient, RAID only adds unnecessary complexity and overhead.

#Modern Mindset: Integrity Over Redundancy

#From Preventing Downtime to Preventing Corruption

Since the 2010s, the RAID debate has shifted. Classic hardware RAID focuses on availability: keeping the array running when a disk dies. In reality, however, most data loss doesn't come from dead disks, but from silent corruption — data that gets damaged without anyone knowing. A dead disk is detected and replaced, but bits that silently change aren't detected until it's too late.

This is why ZFS and btrfs add a checksum to every data block, so that every read verifies integrity. Traditional RAID provides redundancy; ZFS and btrfs add integrity. This difference will shape your choices in episodes 8 and 22.

#RAID as a Foundation, Not Everything

In modern storage architecture, RAID is one layer among several layers of protection: snapshots, replication, offsite backup, and versioning. RAID ensures that one dead disk doesn't kill the service; other layers ensure that human error and disasters don't kill the data. This perspective will color the entire series, especially episode 12 on backup and disaster recovery.

#Mental Model for the Rest of the Series

From now on, get into the habit of evaluating every RAID decision along three axes: capacity, performance, and resilience. Every RAID level is a point between these three axes — no level excels at all of them. When a team picks RAID 10, they trade capacity for write performance and fast rebuilds; when they pick RAIDZ2, they trade parity overhead for safe capacity on large disks. This is the thinking framework you'll use through episode 22.

#Conclusion

Episode 1 gave you context: RAID was born from the 1987 Berkeley paper to make redundant storage affordable, evolved from RAID 1-5 to RAID 6, 10, 50, 60, all the way to dRAID, and is now available in software implementations such as mdadm and ZFS as well as hardware controllers.

Key takeaways:

• RAID was popularized by the Patterson, Gibson & Katz paper at Berkeley in 1987.
• RAID levels 1-5 were born from that paper; RAID 0, 6, 10, and dRAID came later.
• RAID solves three problems: redundancy, performance, and capacity.
• Every level has its own capacity and write-overhead tradeoffs.
• RAID is not a backup: it doesn't protect against human error or physical disasters.
• The modern trend shifts from mere redundancy toward data integrity via checksums.

In the next episode, episode 2, we'll discuss core concepts and RAID levels — striping, mirroring, and parity, the capacity formulas for every level, and the URE tradeoff that makes RAID 6 more attractive for large disks. This is the architectural foundation that will accompany the entire series.