RAID Concept: The Foundation of Redundant Storage

Every database administrator faces an uncomfortable truth: hard drives fail. Not eventually—inevitably. Industry studies consistently show that 2-5% of enterprise drives fail each year, and that failure rate increases dramatically as drives age. In a data center with thousands of drives, multiple failures occur every single week.

For a database system, a drive failure can mean hours of downtime, days of recovery work, or in the worst case—permanent data loss. When your organization's most critical asset is data, the question isn't whether you'll experience a drive failure, but how your system will respond when it happens.

This fundamental challenge gave rise to one of the most important innovations in storage technology: RAID (Redundant Array of Independent Disks)—a family of techniques that transform the unreliability of individual drives into highly reliable, high-performance storage systems.

The story of RAID begins in 1987 at the University of California, Berkeley, where researchers David Patterson, Garth Gibson, and Randy Katz published a seminal paper titled "A Case for Redundant Arrays of Inexpensive Disks". Their insight was revolutionary: instead of relying on expensive, highly-reliable mainframe drives, organizations could achieve better performance AND reliability by combining multiple inexpensive commodity drives.

The Economics of Storage in 1987:

At the time, organizations faced a stark choice:

• Mainframe drives: Extremely expensive ($10,000+), moderately reliable, slow to replace
• Commodity drives: Inexpensive ($1,000), unreliable, easily replaced

The Berkeley researchers recognized that by distributing data across multiple cheap drives and adding redundancy, they could create storage systems that:

1. Were faster than single expensive drives (parallelism across multiple spindles)
2. Were more reliable than single expensive drives (redundancy survives failures)
3. Cost less than equivalent mainframe storage
4. Could be scaled by simply adding more drives

The Three-Pronged Problem:

RAID was designed to address three interconnected problems that plagued storage systems:

1. Reliability Problem: Single drives fail unpredictably. Mean Time Between Failures (MTBF) for a single drive might be 100,000 hours (~11 years), but with 100 drives, you could expect one failure every 1,000 hours (~42 days).

2. Performance Problem: Individual drives have physical limitations—the read/write head can only be in one place at a time. Sequential throughput is limited by rotational speed and track density.

3. Capacity Problem: Single drives have fixed capacity. Upgrading means replacing drives entirely, causing downtime and migration complexity.

RAID addresses all three by treating multiple drives as a single logical unit while strategically distributing data and redundancy information across them.

Before diving into specific RAID levels, we need to establish the fundamental concepts that underpin all RAID implementations. These building blocks combine in different ways to create the various RAID configurations you'll encounter.

1. Disk Array:

A RAID array is a collection of physical drives that the operating system sees as a single logical volume. The RAID controller (hardware or software) manages this abstraction, translating logical I/O requests into physical operations across multiple drives.

2. Striping:

Striping distributes data across multiple drives in segments called stripes. Each stripe consists of stripe units (fixed-size blocks, typically 64KB-256KB) written consecutively across drives. Striping enables parallelism: a single large read can be serviced by multiple drives simultaneously.

3. Mirroring:

Mirroring maintains identical copies of data on two or more drives. Every write operation is duplicated; if one drive fails, the mirror provides immediate access to the same data. Mirroring doubles read performance (either mirror can serve reads) but provides no write performance benefit.

4. Parity:

Parity is a form of error-correction that enables data recovery without full duplication. A parity block is calculated from data blocks using the XOR (exclusive or) operation. Given any N-1 blocks (data or parity), the missing block can be reconstructed.

5. Hot Spares:

A hot spare is an idle drive in a RAID array that automatically replaces a failed drive. When a failure is detected, the RAID controller immediately begins rebuilding data onto the hot spare—often before an administrator even knows about the failure. Hot spares minimize the vulnerability window during which a second failure would cause data loss.

6. Rebuild and Degraded Mode:

When a drive fails in a RAID array with redundancy, the array enters degraded mode. It continues to function, but:

• Performance may be reduced (reads require parity calculations; writes require additional I/O)
• A second failure could be catastrophic (depending on RAID level)
• The controller begins rebuilding—reconstructing lost data onto a replacement drive

Rebuild time depends on drive capacity, array size, and system load. For modern large drives, rebuilds can take hours to days—a critical consideration when planning RAID configurations.

Understanding how RAID is implemented helps inform decisions about array configuration. RAID can be implemented at different layers of the storage stack, each with distinct tradeoffs.

Hybrid Approaches:

Modern storage architectures often combine approaches:

HBA + Software RAID: Use a simple Host Bus Adapter (HBA) to connect drives, then manage RAID in software. This provides maximum flexibility with ZFS or Linux md while avoiding hardware RAID vendor lock-in.

SAN/NAS RAID: Enterprise storage arrays (NetApp, Pure Storage, EMC) implement RAID internally, presenting simple volumes to servers. The RAID complexity is hidden within the storage appliance.

Cloud Block Storage: Cloud providers (AWS EBS, Azure Managed Disks) handle redundancy transparently. Users specify durability requirements; the provider manages replication and availability.

When evaluating and comparing RAID configurations, you'll encounter specific terminology and metrics. Understanding these is essential for making informed decisions.

Performance Metrics:

IOPS (I/O Operations Per Second): Measures random I/O performance—critical for database workloads with many small, random requests. RAID levels affect IOPS differently:

• Striping (RAID 0, 10) scales IOPS linearly with drive count
• Parity RAID (RAID 5, 6) has reduced write IOPS due to parity overhead

Throughput (MB/s): Measures sequential I/O performance—important for data warehousing, backups, and streaming workloads. Striping improves throughput by parallelizing sequential reads across multiple drives.

Latency: Time to complete an individual I/O operation. Mirroring can reduce read latency (reads from nearest/fastest mirror); parity RAID can increase read latency in degraded mode.

Database systems have specific I/O patterns that influence RAID selection. Understanding these patterns helps match RAID configurations to workload requirements.

Transaction Log I/O:

Transaction logs (WAL in PostgreSQL, redo logs in Oracle, binary logs in MySQL) demand:

• Sequential writes: Logs are append-only, favoring throughput over IOPS
• Write durability: Logs must hit stable storage before transactions commit
• Low latency: Commit latency directly impacts application response time

RAID 10 is often recommended for transaction logs: mirroring provides durability without parity overhead, and the write operations benefit from parallel mirrored writes with low latency.

OLTP vs. OLAP Workloads:

OLTP (Online Transaction Processing):

• Many small, random reads and writes
• Low latency critical
• Write-intensive (order entry, account updates)
• Recommendation: RAID 10 for data files; parity RAID's write penalty is problematic

OLAP (Online Analytical Processing):

• Large sequential scans
• Read-intensive (reporting, analytics)
• Throughput more important than latency
• Recommendation: RAID 5/6 acceptable; parity overhead is less impactful on reads; higher capacity efficiency valuable for large datasets

Modern SSD Considerations:

Solid-state drives have changed some RAID calculations:

1. Parity overhead is reduced: SSDs are fast enough that the parity calculation and additional I/O operations have less relative impact
2. Write endurance matters: Parity RAID generates additional write operations that consume SSD write cycles faster
3. Rebuild times are shorter: Fast SSD I/O accelerates rebuild, reducing the vulnerability window
4. IOPS are abundant: A single NVMe SSD can deliver 100,000+ IOPS, making RAID less necessary for performance (though still critical for durability)
5. Hardware RAID value diminishes: Modern CPUs can handle parity calculations without noticeable impact; software RAID with SSDs is highly viable

RAID's primary purpose is improving storage reliability. Understanding how to analyze reliability mathematically helps inform configuration decisions and capacity planning.

Mean Time To Data Loss (MTTDL):

MTTDL calculates expected time before an unrecoverable failure. It depends on:

• MTBF: Mean Time Between Failures for individual drives
• MTTR: Mean Time To Repair (rebuild time after failure)
• N: Number of drives in the array
• Fault tolerance: Number of failures the array survives

Correlated Failures:

The MTTDL calculations above assume independent, random failures. In practice, failures are often correlated:

1. Batch Effects: Drives manufactured in the same batch may have similar defects, failing around the same time
2. Environmental Stress: Power surges, temperature spikes, or vibration affect all drives simultaneously
3. Workload Stress: Heavy array rebuild stresses surviving drives, increasing their failure probability
4. Undetected Errors: Latent sector errors (unreadable sectors) may only be discovered during rebuild

Latent Sector Errors (LSE):

A particularly insidious reliability threat. A drive may have unreadable sectors that aren't discovered until a read is attempted—often during a rebuild after another drive failed. Studies show 3-8% of drives exhibit LSEs after 3 years.

This is why RAID 6 (tolerating 2 failures) is increasingly essential: even if only one drive 'fails,' LSEs on surviving drives can prevent successful rebuild.

We've established the foundation for understanding RAID technology. Let's consolidate the key concepts:

What's Next:

With these foundational concepts established, we're ready to explore the specific RAID levels in detail. The next page examines RAID 0, 1, 5, 6, and 10—their architectures, performance characteristics, capacity efficiency, and appropriate use cases. You'll learn to select the right RAID level for specific database workloads and reliability requirements.