I found silent data corruption on my NAS months later because I ignored one scrub setting

Published Aug 4, 2026, 10:00 AM EDT Korbin is a Linux system administrator who spends most of his time in a terminal figuring out how things actually work. Over the last decade he's written hundreds of articles about Linux configuration, troubleshooting weird problems, and using open-source tools in the real world. He also works a lot with Windows systems and networking, especially in mixed environments where things don't always behave the way the documentation says they should. Writing things down is how he makes sense of it all and hopefully saves someone else a few hours. One of the biggest advantages of ZFS over traditional file systems is that it verifies data integrity, rather than assuming the storage device always has the correct data. It does so by maintaining a checksum for each file on disk and flagging any mismatches during scheduled scrubs. The problem is when a user doesn't perform regular scrubs. On TrueNAS, periodic scrub tasks are turned on by default, and they're scheduled from the time you first make a pool. It's a nice touch that encourages people to use ZFS as intended, but many don't bother to check the default settings or tweak them. I had this happen on my own RAIDZ2 pool where faulty non-ECC RAM corrupted numerous files, and the problem wasn't caught until months later because I didn't have scrubs running on a schedule. Once I enabled the task and selected a schedule for them to run on (I chose once per month), ZFS found the corrupted files and rebuilt them from parity data. I replaced that bad RAM stick and now keep scrubs running regularly to protect from future silent data corruption. Make sure scrub tasks are running periodically A scrub works by walking every allocated block in the pool, recalculating its checksum, and comparing that against the checksum that ZFS recorded when the block was written. If they don't match, ZFS rebuilds the block from parity or from a mirrored copy before moving on. It's how ZFS catches corruption in data that you aren't actively using, because ZFS otherwise verifies a block any time something opens it. For files you work with every week, they effectively check themselves on a regular basis. As for an archive of old records you haven't accessed in a few years, nothing is checking their integrity other than a scrub. There's a setting in TrueNAS that tripped me up when I first set up a scrub schedule. You start by selecting how often you want the task to run, with suggested options such as weekly or monthly. But there's an extra setting called Threshold Days with a default of 35 days. This means that even if you configure scrubs to run weekly, the event will only trigger if 35 days have elapsed since the last run. So, the interface shows a weekly schedule, but the pool is actually only scrubbed every five weeks. Verify the schedule instead of trusting it One command confirms if scrubs are really running If in doubt about the most recent scrub, the most reliable way is to check from the shell by running zpool status -v. The output includes the date, duration, and result of the most recent completed scrub, along with the amount of data repaired. It's worth running the command to confirm that scrubs are happening as often as you think they are; it only takes a second to check. Ideally, you'll usually see that the scrub completed with zero repairs needed. If ZFS is regularly needing to repair blocks of data, it indicates a problem with the storage device or RAM. When I saw my scrubs regularly repairing more and more data each time, I ran a test on my memory and determined that one module had failed. But the scrubs are what alerted me to the problem and prevented me from permanently losing data. I like TrueNAS's web GUI for scheduling scrubs and checking storage health, but you can run ZFS commands directly from the shell to get the same information if you prefer the command line or aren't on TrueNAS. The zpool scrub tank command starts a scrub immediately, or you can add it to cron if you want it on a schedule. Doesn't frequent scrubbing wear out hard drives? Short answer: not really A scrub is hours of sustained sequential reads across every disk simultaneously, and pool performance noticeably degrades while one is active. Many users conclude that hammering aging hard drives only exacerbates problems, and some with non-ECC RAM still fear the "scrub of death" story, which isn't nearly as scary as it sounds. In reality, a scrub is a read-only operation unless it needs repairs, and the cumulative workload it places on the drives is trivial compared to what any modern hard drive is rated to handle. If a scrub does manage to push a failing hard drive over the edge, all it really did was expose a problem that was going to surface pretty soon anyway. I have my scrubs set to monthly, but once every two weeks is also reasonable. A pool nobody verifies isn't really protected Redundancy only saves your files when there's something checking that they haven't silently gone bad. The default scrub schedule pushes the interval further than most people realize, so it's worth taking two minutes to check the UI or the output of zpool status to make sure that ZFS is performing scrubs the way you expect. It saved some of my files from silent data corruption, so now it's the first thing I check on any new pool I create.