Patrol Reads, Consistency Checks and Silent Data Corruption
The sectors that kill a RAID array are not the ones that failed loudly. They are the ones that went bad months ago on a part of the disk nothing had read since, sat there unnoticed, and then turned up during a rebuild when the array had no redundancy left to recover them.
Patrol reads and consistency checks exist to find those sectors while the array is still healthy. This guide explains what each one does, why they are different jobs, what hardware RAID can and cannot detect about corrupted data, and how to schedule them without wrecking performance.
The problem they solve
A drive can develop a bad sector at any time. If nothing reads that sector, nothing notices. The drive does not announce it, the controller does not know, and the array reports optimal.
These are called latent sector errors, and on a large array there is a lot of capacity that is rarely read. Archive volumes, old backup sets, cold portions of a file server: months can pass without those blocks being touched.
The moment they matter is a rebuild. Rebuilding a parity array requires reading every block on every surviving drive. If one of those reads hits a latent error, the controller cannot reconstruct that stripe, because the redundancy it would have used is the drive that already failed. On single parity, that is data loss inside an operation you were running to avoid data loss.
Enterprise drive datasheets quote an unrecoverable read error rate, typically in the region of one error per 10^15 or 10^16 bits read. Those numbers look reassuring until you multiply them by the number of bits in a full-array read of a modern multi-terabyte set. Our guide on RAID levels covers why this pushed the industry toward double parity.
Patrol read
A patrol read walks the drives in the background and reads sectors that nothing has asked for, specifically to find problems early. Vendors call it different things — patrol read, surface scan analysis, media scan — and it does the same job.
When it finds an unreadable sector while the array is healthy, the controller can rebuild that block from parity or the mirror and write it back, and the drive remaps it. The error is corrected quietly at a moment when correcting it costs nothing.
This is the single most valuable background task on a hardware RAID controller, and it is usually enabled by default. Confirm it actually is on your controllers rather than assuming, because it gets disabled during performance troubleshooting and never re-enabled.
Consistency check
A consistency check is a different job. It reads the data and the parity across a redundant volume and verifies that the parity matches what the data says it should be.
A mismatch means something has gone wrong: a write that did not complete fully, a firmware bug, a marginal cable, or corruption somewhere in the path.
Here is the limitation nobody explains. When a consistency check finds a mismatch on a single-parity array, it knows data and parity disagree. It does not necessarily know which one is wrong. Controllers typically resolve this by recalculating parity from the data and rewriting it, which is the reasonable default and is also an assumption. If the data was the corrupted side, the controller has just made the corruption permanent by generating matching parity for it.
This is not a reason to skip consistency checks. It is a reason not to believe that hardware RAID protects data integrity the way a checksumming filesystem does.
What hardware RAID cannot see
If a drive returns data that is wrong but reports success, hardware RAID has no way to know. There is no checksum on the data itself, only parity across drives, and parity only tells you something disagrees, not what the right answer was.
Silent corruption of this kind is rare per drive and stops being rare across a large estate over years. Three things address it:
Checksumming filesystems. ZFS and Btrfs checksum every block and verify on every read, so corrupted data is detected and, where redundancy exists, repaired with certainty about which copy was right. This is a genuine architectural advantage over hardware RAID, and it is one reason software-defined storage displaced controllers for some workloads. Our guide on RAID controller versus HBA in IT mode covers why those platforms want direct drive access.
T10 protection information, sometimes seen as DIF or 520-byte sectors, adds integrity metadata to each block so errors can be caught in transit. Enterprise SAS drives and arrays support it; it is not universal and it changes the sector format, which matters when sourcing replacements.
ECC memory. Corruption that happens in RAM before the data ever reaches a drive is invisible to every storage-layer protection. See ECC versus non-ECC memory.
Scheduling without hurting performance
Both tasks consume the same controller and drive resources as your workload, and both have a rate setting alongside the rebuild rate.
Run them, but schedule them. Weekly or monthly is typical. What matters more than the exact interval is that the window does not collide with your busy period, your backup, or anything else heavy.
Do not let them run during a rebuild. A consistency check that starts on schedule mid-rebuild competes directly and extends the exposure window, which is the opposite of what you want. Our guide on RAID rebuild speed and priority covers that interaction.
Match the interval to the risk. Large drives and single parity justify more frequent scanning, because the rebuild you are protecting against is longer and less forgiving. A small mirrored pair needs it less.
Act on what they report
These tasks are only useful if someone sees the output. A patrol read that corrects sectors on the same drive month after month is telling you that drive is failing, even though it has not failed and the array still reports optimal.
Rising reallocated or pending sector counts are the signal to replace a drive proactively, before it forces a rebuild at a time of its choosing. Our guide on reading drive health data covers which attributes actually predict failure.
Alert on consistency check mismatches specifically. A mismatch is not routine, and on an array that has never reported one, the first is worth investigating rather than clearing. See hardware monitoring.
And the obvious point: none of this is backup. Scrubbing protects against media decay, not deletion, ransomware or a controller writing garbage confidently. See the 3-2-1 rule.
Sourcing
We supply enterprise SAS and SATA drives with carriers matched to the server generation, plus RAID controllers and cache modules for Dell PERC, HPE Smart Array and LSI platforms. If patrol reads are flagging sectors on a drive and you want to replace it before it fails, send us the service tag or an existing drive part number and we will match capacity, interface, speed and sector format. Request a bulk quote or email sarah.jane@techsellerusa.com.
Common questions
What is a patrol read?
A background task where the controller reads sectors nothing has asked for, specifically to find bad ones early. If it finds an unreadable sector while the array is healthy, it can rebuild that block from parity or the mirror and write it back so the drive remaps it. Vendors also call this surface scan analysis or media scan. It is usually on by default, but it gets disabled during performance troubleshooting and often never re-enabled.
How is a consistency check different?
A patrol read looks for sectors that cannot be read. A consistency check reads the data and the parity and verifies they agree. They catch different problems: one finds media decay, the other finds writes that did not complete, firmware bugs or corruption in the path. Both are worth running, and neither substitutes for the other.
Why do latent sector errors matter so much during a rebuild?
Because a rebuild reads every block on every surviving drive, and by then the redundancy that would have recovered a bad block is the drive that already failed. On single parity, hitting an unreadable sector mid-rebuild means losing that stripe during the very operation meant to restore protection. Finding those sectors while the array is healthy costs nothing; finding them during a rebuild can cost the array.
Does a consistency check fix corrupted data?
Not reliably, and this is the part that is rarely explained. On a single-parity array the check knows data and parity disagree but not necessarily which side is wrong. Controllers typically recalculate parity from the data and rewrite it, which is a reasonable default and also an assumption. If the data was the corrupted side, the controller has just made the corruption permanent by generating matching parity for it.
Can hardware RAID detect silent data corruption?
Not really. If a drive returns wrong data and reports success, there is no checksum on the data itself for the controller to compare against, only parity across drives, and parity tells you something disagrees rather than what the right answer was. Checksumming filesystems such as ZFS and Btrfs verify every block on every read and can repair with certainty about which copy was correct. T10 protection information and ECC memory address other parts of the same problem.
How often should these run?
Weekly or monthly is typical, and the interval matters less than the scheduling. Keep the window clear of your busy period and your backup, and make sure neither task can start during a rebuild, because it competes directly and extends the exposure. Larger drives on single parity justify more frequent scanning, since the rebuild being protected against is longer and less forgiving.
If a patrol read is flagging sectors and you want to replace the drive before it forces a rebuild, send us the service tag or an existing part number.
