How Can RAID Parity Remain Valid When NAS Data Is Corrupted?

RAID parity can remain mathematically valid while NAS data is wrong because parity usually proves that the current blocks satisfy a redundancy equation. It does not prove that those blocks contain the historically correct file content.

If corrupted data is written through the normal storage path, the RAID layer may calculate matching parity for that corrupted data. The stripe is internally consistent, yet the file can still be logically or silently damaged.

What Does RAID Parity Actually Validate?

Parity is a relationship among blocks in a stripe. In a simplified single-parity example, the data blocks and parity block are connected by an XOR equation. If one block is missing, the others can recreate it.

That equation answers a narrow question: do these current block values fit the expected parity relationship? It does not answer whether a photo still contains the pixels the user originally saved, whether a database page reflects the latest committed transaction, or whether malware changed the file intentionally.

How Can Wrong Data and Correct Parity Coexist?

Suppose a bad memory path, software defect, application bug, or already-corrupted source produces the wrong data before RAID calculates parity. The storage stack writes the wrong data and updates parity from that same wrong value. Both writes can complete perfectly.

The resulting stripe is coherent from RAID's perspective. A later parity check can find no mismatch because the equation is still true. The failure happened above the parity layer, so parity has no independent record of the intended content.

Why Is a RAID Write Hole a Different Problem?

A write hole occurs when a stripe update is interrupted after only part of the data-and-parity change reaches stable storage. The stripe can then contain a mixture of old and new values. This is parity inconsistency, not the “wrong data with matching parity” case.

Linux MD's partial parity log documentation explains that PPL closes the RAID 5 write hole by recording partial parity before the main stripe update. It also notes an important boundary: protecting parity consistency does not automatically protect in-flight user data from every failure mode.

RAID journals described in the Linux device-mapper RAID documentation solve the same class of non-atomic component updates. They keep the parity equation coherent after an interrupted write, but they cannot determine whether the application supplied the right bytes.

What Adds End-to-End Integrity?

End-to-end checksums add a separate identity for a data block or record. A scrub can recompute the checksum and compare it with the stored value. If one redundant copy fails validation and another passes, the system has evidence about which copy is trustworthy.

Btrfs scrub documentation describes checking data and metadata for checksum and read errors, then repairing from a verified replica when one is available. That is different from relying on parity alone to say that a stripe equation balances.

The checksum must also be protected and stored through a trustworthy path. If both content and its checksum are overwritten together with a logically wrong new version, the system can verify that wrong version consistently.

Where Does RAID Still Help?

Parity remains valuable for drive failure and unreadable-block recovery. It can reconstruct missing information, preserve availability, and support repair when the failure falls inside the RAID model. The mistake is asking parity to prove application correctness, historical truth, or independence from the same storage stack.

This boundary is part of the limits of RAID for home NAS data protection. RAID, checksums, snapshots, and backups answer different questions and become stronger when they are layered rather than treated as interchangeable.

FAQ

Does a successful parity check prove every file is correct?

No. It proves the checked stripes satisfy their current parity relationships. Files can still be logically wrong, maliciously changed, or consistently corrupted above the RAID layer.

Can checksums identify the correct copy?

They can distinguish a copy that matches its stored checksum from one that does not. Repair still requires a valid redundant copy or backup, and a checksum cannot detect a bad version that was legitimately checksummed after being written.

Is RAID journaling the same as filesystem journaling?

No. RAID journaling protects array update consistency, especially data-and-parity relationships. Filesystem journaling protects filesystem transaction consistency such as metadata updates.

Final Takeaway

Valid parity means the current stripe is mathematically self-consistent. It does not mean the bytes are the intended bytes. End-to-end checksums, transaction semantics, snapshots, and independent backups are needed to answer the broader integrity and recovery questions that parity cannot.