The Evolution of Redundancy Part 3: Beyond RAID

Too Long; Didn't Read

Beyond RAID: ZFS, Distributed Storage, and the Rise of Software Defined Redundancy

For decades, RAID was the answer to one of storage’s biggest problems: disks fail.

Whether it was RAID 1 mirroring critical operating systems or RAID 5 balancing capacity with redundancy, the objective remained the same. If a drive died, the system stayed online and the data survived.

The first two parts of this series explored how redundancy evolved to meet that challenge. We started with striping and mirroring, moved into parity-based protection, and examined how RAID 5, RAID 6, and RAID 10 became the foundation of modern storage systems.

For a long time, that foundation held up remarkably well. But storage systems didn’t stop growing.

A RAID 5 array built from a handful of 36GB drives behaves very differently from one built from multi-terabyte disks. As capacities increased, rebuild operations that once took a few hours began stretching into entire days. During that period, arrays remained vulnerable, and the probability of encountering additional failures increased with every terabyte that had to be read.

In Part 2, we discussed Unrecoverable Read Errors (UREs) and why they became a growing concern for large parity-based arrays. The larger the disks became, the more likely it was that a rebuild operation would encounter an unreadable sector before completion.

The problem wasn’t that RAID had stopped working. The problem was that storage systems had outgrown some of the assumptions RAID was originally designed around.

At the same time, another issue was becoming increasingly difficult to ignore.
A RAID controller can detect a failed drive. It can rebuild missing parity. It can reconstruct lost blocks.

What it cannot do is determine whether the data stored inside those blocks is actually correct.

As infrastructure scaled, storage architects began realizing that hardware redundancy alone was no longer enough. Protecting disks and protecting data were not necessarily the same thing. That realization marked the beginning of the next stage in the evolution of redundancy.

The Architectural Limit of Traditional RAID

Traditional RAID operates at the block level. It doesn’t know whether a block belongs to a database, a virtual machine, a log file, or an operating system. Its job is simply to distribute, mirror, or reconstruct blocks according to the configured RAID level.

For the workloads RAID was originally designed for, that approach worked extremely well. The challenge is that RAID assumes the data it receives is already correct.

As long as parity calculations match and the disks respond as expected, the array considers everything healthy. It has no built-in mechanism to verify whether the contents of a block have changed unexpectedly due to a firmware bug, memory corruption, controller issues, or media degradation.

This is where concepts like silent data corruption and bit rot enter the conversation.

Unlike a failed drive, silent corruption doesn’t trigger alarms. The disk remains online. SMART reports may appear normal. The array itself may continue operating without any indication that a problem exists.

From RAID’s perspective, the corrupted block is simply another block.

In mirrored configurations, corrupted data can be copied to multiple drives. In parity-based arrays, corrupted blocks may even participate in future rebuild operations. The redundancy remains intact, but the integrity of the data may already be compromised. This distinction became increasingly important as storage capacities grew.

A failed disk is an obvious event. Administrators know something is wrong and can respond accordingly.

Corruption is different.
Data can remain untouched for months or even years before anyone attempts to read it. By the time the problem is discovered, every redundant copy may already contain the same corrupted information.

Traditional RAID was built to solve hardware failure.

Modern storage systems increasingly needed to solve data integrity problems.

The industry wasn’t abandoning RAID. It was simply encountering challenges that existed above the block layer, challenges that RAID was never designed to address.

The next step in redundancy would come from systems that understood not just where data was stored, but whether that data remained correct over time.

ZFS – When the Filesystem Becomes the Storage Controller

One of the biggest changes in modern storage wasn’t a new RAID level or a faster controller.

It was the idea that redundancy, volume management, and the filesystem shouldn’t be treated as separate layers.

Traditional storage stacks split these responsibilities apart. A RAID controller handled redundancy, a volume manager handled storage allocation, and a filesystem sat on top organizing data. Each layer did its job independently, often with very little awareness of what was happening above or below it.

ZFS took a different approach.

Instead of stacking multiple technologies together, it combined them into a single storage platform. The same system responsible for storing data also became responsible for verifying and protecting it.

That architectural shift solved several long-standing problems that traditional RAID struggled with.

Checksums and End-to-End Integrity

One of the most significant additions was end-to-end checksumming.

Every block written to a ZFS pool receives a checksum that is stored separately from the block itself. Whenever that data is read, ZFS verifies the checksum before returning the information to the application.

If the values don’t match, ZFS knows the data has been corrupted.

More importantly, if redundancy exists elsewhere in the pool, ZFS can retrieve a healthy copy and repair the damaged block automatically.

This changes the conversation entirely.

Traditional RAID focuses on whether a disk can be read.

ZFS focuses on whether the data being read is still correct.

A drive can be perfectly healthy while returning corrupted information. ZFS was designed around that reality.

Copy-on-Write and the End of the Write Hole

In Part 2, we discussed one of the long-standing weaknesses of parity-based RAID systems: the write-hole problem.

            Traditional RAID                 ZFS Copy-on-Write

        ┌──────────────────┐           ┌──────────────────┐
        │ Existing Block A │           │ Existing Block A │
        └────────┬─────────┘           └────────┬─────────┘
                 │                              │
                 ▼                              ▼
         Overwrite Block                Write New Block
                 │                              │
         ⚡ Power Failure               ✓ Verify Checksum
                 │                              │
         Partial Write                 ✓ Update Metadata
                 │                              │
         ❌ Data/Parity Risk           ✓ Free Old Block
                 │                              │
         Possible Write Hole           Original Data Safe

A typical RAID 5 or RAID 6 array updates both data blocks and parity blocks during a write operation. If power is lost midway through that process, the data and parity information can become inconsistent.

The array survives.

The data may not.

ZFS approaches writes differently through a design known as Copy-on-Write (CoW).

Rather than modifying existing blocks in place, ZFS writes changes to new blocks and updates metadata only after the entire write operation has completed successfully.

The original data remains untouched until the new version is fully committed.

As a result, sudden power loss cannot leave partially updated parity stripes behind. The write-hole problem effectively disappears because existing data is never overwritten during the write process.

This approach improves consistency, but it also explains why ZFS sometimes behaves differently from traditional storage systems. The priority is correctness first, performance second.

RAID-Z – Parity With Context

At first glance, RAID-Z looks similar to RAID 5 or RAID 6.

Both use parity.

Both provide fault tolerance.

Both allow systems to continue operating after drive failures.

The difference lies in awareness.

Traditional RAID controllers operate blindly at the block layer. They distribute data according to predefined stripe layouts without understanding how that data relates to the filesystem above.

RAID-Z operates within ZFS itself. Because ZFS understands both the data and the storage layout, parity calculations occur with complete awareness of how information is being written. This integration eliminates several inefficiencies and consistency problems that traditional parity arrays have historically faced.

The result isn’t just another parity implementation.
It’s parity designed around data integrity rather than simple disk recovery.

Scrubbing – Finding Problems Before They Become Disasters

One of the most useful concepts introduced by ZFS is the scrub.

A scrub systematically reads data across the pool, verifies checksums, and checks for corruption long before users encounter it.

Think of it as preventative maintenance for data.

Traditional RAID typically discovers problems when a disk fails or when corrupted data is accessed. ZFS actively searches for issues while the system is still healthy.

For large storage systems, this can make a significant difference.

Finding corruption during a scheduled scrub is far better than discovering it during a rebuild when the system is already operating in a degraded state.

For many administrators, this became one of the most compelling reasons to adopt ZFS.

It wasn’t just protecting drives.

It was continuously validating the integrity of the data itself.

Distributed Storage – Redundancy Beyond the Server

ZFS addressed many of the problems that traditional RAID couldn’t solve.

It verifies data integrity, detects corruption, and removes several long-standing weaknesses associated with parity-based storage. But even ZFS has an assumption built into its design. The system still lives inside a single machine.

If the server loses power, suffers a motherboard failure, or disappears from the network entirely, redundancy within that machine can only help so much. As infrastructure evolved, organizations began facing a different class of failures. The concern was no longer just losing a disk. It was losing entire servers.

In some environments, entire racks.

Eventually, entire data centers.

This shift pushed redundancy beyond the boundaries of a single storage system.

Ceph and the Rise of Cluster-Level Redundancy

Ceph approaches storage from a fundamentally different perspective.

Instead of distributing data across disks, it distributes data across nodes.

Every piece of data is stored according to rules that determine where replicas or erasure-coded fragments should live within the cluster. When hardware fails, the cluster automatically redistributes data to maintain the desired level of protection.

One of the reasons Ceph scales so effectively is its CRUSH algorithm.

Traditional storage systems often rely on centralized metadata services or lookup tables to determine where data is stored. As clusters grow, those systems can become bottlenecks.

CRUSH takes a different approach.

Rather than asking a central controller where data should live, every node independently calculates data placement using the same set of rules. This eliminates a central point of coordination and allows clusters to scale to thousands of storage devices without introducing significant placement overhead.

From an operational perspective, this means recovery becomes part of normal cluster behavior.

When a node disappears, administrators don’t rebuild arrays.

The cluster rebalances itself.

Erasure Coding – RAID Mathematics at Infrastructure Scale

The underlying concepts behind erasure coding are surprisingly familiar.

In Part 2, we explored how RAID 5 and RAID 6 use parity to reconstruct missing data after a drive failure. Erasure coding applies the same idea, but on a much larger scale. Instead of distributing parity across disks, erasure coding distributes data and parity fragments across multiple servers.

A common configuration might use an 8+3 layout.

Eight fragments contain data.

Three fragments contain parity information.

As long as enough fragments remain available, the original data can be reconstructed even if multiple nodes fail simultaneously.

The advantage is efficiency. Traditional three-way replication stores three complete copies of the same data. Erasure coding provides similar durability while requiring significantly less storage overhead.

This is one of the reasons modern object storage platforms and large cloud providers rely heavily on erasure coding. The mathematics behind RAID never disappeared. It simply expanded beyond the limits of a single server.

When Redundancy Becomes a Service

Modern object storage platforms push this idea even further.

Whether it’s an on-premises deployment or a cloud-based storage service, administrators increasingly interact with storage through APIs rather than disks, arrays, or controllers.

Behind the scenes, replication, erasure coding, integrity verification, and automated recovery are still happening. The difference is that these mechanisms are no longer configured individually.

They are built into the platform itself.

At this stage, redundancy stops being a hardware feature and becomes a property of the entire storage system. The focus shifts from protecting drives to maintaining data availability regardless of which components fail underneath.

The Real Evolution of Redundancy

Looking back across this series, one thing becomes clear. The history of redundancy isn’t a story about replacing technologies. It’s a story about expanding the scope of what needs protection.

For decades, those ideas formed the foundation of enterprise storage, and they still do. The reason RAID remains relevant today is because the underlying principles never stopped working. Disks still fail. Hardware still breaks. Redundancy is still necessary.

What changed was the scale of the problem. As storage systems grew larger, protecting hardware was no longer enough. Administrators had to consider silent corruption, extended rebuild windows, and failures that occurred far beyond the boundaries of a single disk.

ZFS addressed many of those concerns by making storage aware of the data it was protecting. Distributed storage platforms extended the same philosophy across clusters, racks, and entire infrastructures. Each step built upon the ideas that came before it.

Parity didn’t disappear. Mirroring didn’t disappear. RAID didn’t disappear. They evolved.

Today, a modern storage platform may use RAID inside a server, checksums inside the filesystem, erasure coding across a cluster, and replication between data centers. The layers have multiplied, but the objective remains the same as it was when the first RAID research paper appeared decades ago. Keep the data available when something fails. The difference is that modern systems are no longer designed around the assumption that failures are rare.

That’s the real evolution of redundancy.

Not simply surviving failure, but designing systems that assume failure from the very beginning.

Please follow and like us: