A healthy TrueNAS disk routine runs two scheduled jobs: a ZFS scrub that verifies and self-heals your data, and SMART self-tests that catch a drive degrading before it dies. For a home pool, a sensible schedule is:
- ZFS scrub — every two weeks or monthly, in an idle window; this is a suggested home schedule.
- SMART SHORT test — daily or weekly; it is cheap, so nightly is fine.
- SMART LONG test — monthly, scheduled off-peak.
Stagger the three so they never run at once. Snapshots and replication protect your data against accidents and disasters; scrubs and SMART tests protect against the slower, quieter threat of disks degrading and bits silently rotting. They’re the maintenance layer most home NAS users set up once and forget, which is fine, because “set up once correctly” is exactly the goal. This guide explains what each does, how they complement each other, and what schedule actually makes sense for a home pool.
Two different jobs
ZFS scrubs and SMART tests are often mentioned together but they check different things, and you want both.
A ZFS scrub verifies your data. It reads every used block in the pool, recomputes its checksum, and compares it to the stored checksum. If a block is corrupt and the pool has redundancy (mirror or RAIDZ), ZFS repairs it from a good copy — this is ZFS “self-healing.” A scrub catches silent data corruption (bit rot, a flaky cable, a drive returning bad data without erroring) before it spreads or before you discover it during a resilver when it’s too late.
A SMART test verifies the drive hardware. SMART (Self-Monitoring, Analysis and Reporting Technology) is built into the drive; a SMART self-test exercises the drive’s own surface and electronics and reports developing problems — reallocated sectors, pending sectors, read errors, temperature, wear. SMART catches a drive that’s failing before it fails completely.
The two are complementary: SMART warns you about degrading drives before they die; ZFS (via scrubs) catches drives that return bad data or fail without warning. Run both.
How they work together on TrueNAS
TrueNAS layers disk protection: ZFS detects sudden failures in real time during normal I/O; the TrueNAS middleware polls SMART data from each drive in the background; and your scheduled scrub and SMART self-tests proactively surface problems on a cadence. You see the results in the pool status (a scrub reports repaired/unrecoverable errors) and in the disk’s SMART report (test pass/fail and the attribute counters).
SMART test types
There are two self-tests you’ll schedule:
- SHORT test — a quick electrical/mechanical check, completes in minutes, negligible performance impact. Safe to run frequently (nightly or every few days).
- LONG test — a full surface scan of the entire drive. Thorough, but it takes hours on large drives and has a real performance impact while running. Run it less often (e.g., monthly), at a quiet time.
A sensible home schedule
For a home pool, start with monthly scrubs, or roughly every two weeks when the maintenance window allows. This is an editorial starting point, not a universal vendor default: inspect the task already configured on your installed release. A reasonable home routine:
| Task | Frequency | Notes |
|---|---|---|
| ZFS scrub | Every 2 weeks or monthly | Schedule for an idle window |
| SMART SHORT test | Daily or weekly | Cheap; nightly is fine |
| SMART LONG test | Monthly | Hours-long; schedule off-peak |
One scheduling rule matters: don’t let these tasks overlap. A SMART long test, a scrub, and a snapshot-replication run all hitting the disks at once thrash performance and can interfere with each other. Stagger them — e.g., scrub on the 1st and 15th overnight, short SMART nightly at a different hour, long SMART on a weekend morning when nothing else runs.
In the cited TrueNAS 25.04 interface, scrubs are under Data Protection → Scrub Tasks and SMART tests under Data Protection → S.M.A.R.T. Tests. Later releases can move or replace these controls; use documentation for the installed version. Check the scrub’s Threshold days as well as its calendar schedule: a scheduled opportunity can be skipped if too little time has elapsed since the last scrub. The scrub task API documents both settings.
Reading the warning signs
The point of all this is early warning. The attributes that genuinely predict failure on spinning disks:
- Reallocated Sector Count — sectors the drive has remapped because they went bad. A few may be tolerable; a rising count is a drive on its way out.
- Current Pending Sector Count — sectors flagged bad but not yet reallocated. Non-zero and climbing is a red flag.
- Offline Uncorrectable — sectors the drive couldn’t read or fix.
- UDMA CRC Error Count — often a cable/connection problem, not the drive itself; reseat or replace the SATA cable before condemning the disk.
For SSDs/NVMe, watch media wearout / percentage used and available spare. A scrub reporting repaired checksum errors on one disk repeatedly is itself a signal that disk (or its cable) is suspect even if SMART looks clean.
Configure email/alerts so TrueNAS tells you when a test fails or an attribute crosses a threshold — silent monitoring you never look at protects nothing.
When to act
- SMART test fails, or pending/reallocated sectors are climbing: plan to replace that drive. Order a replacement now and follow the degraded-pool disk replacement steps; don’t wait for total failure, especially mid-resilver risk on wide RAIDZ.
- Scrub reports unrecoverable errors: the pool found corruption it could not repair (no good copy existed). This means you’ve lost redundancy somewhere or have a real data-loss event — investigate immediately and lean on your replication backups.
- Repeated CRC errors on one disk: suspect the cable/backplane first.
How long does a scrub take, and is the NAS usable during one?
A scrub checks allocated data, so duration depends on pool occupancy, storage performance and competing work. The pool remains accessible, but scrub I/O can slow foreground workloads. Inspect progress and the completion report with zpool status. OpenZFS distinguishes pause from stop: a paused scrub can resume from its checkpoint, while stopping cancels the run. Use the controls documented for your installed TrueNAS version.
FAQ
What is a TrueNAS scrub?
A TrueNAS scrub is a scheduled or manually started ZFS integrity check. It reads allocated data and verifies block checksums to look for corruption, including data that normal file access has not read recently.
What does a scrub do in TrueNAS?
It checks stored data and attempts repair where a healthy redundant copy or sufficient parity is available. The completion report distinguishes repaired data from errors ZFS could not repair; a successful check is not a backup.
What is a pool scrub in TrueNAS?
A pool scrub checks allocated data across the selected pool, including its datasets. It is different from a SMART self-test, which runs inside a drive and checks that device rather than ZFS block checksums.
What does scrubbing a ZFS pool mean?
Scrubbing means checking existing data for integrity, not erasing the pool. It also differs from resilvering, which reconstructs data needed on a replacement or newly attached device. OpenZFS does not run a scrub and resilver concurrently on the same pool.
From a SMART warning to a drive replacement
When a SMART test fails or sectors start climbing, the goal is to swap the drive before it fails outright. On a redundant pool you can do this live: the pool drops to DEGRADED while the old disk is replaced and ZFS resilvers onto the new one. The full procedure, including how to identify the right physical disk and avoid the common mistakes, is in replacing a failed disk on a degraded pool. The reason to act on the warning rather than the failure is resilver risk: a wide RAIDZ vdev rebuilding onto a fresh disk is the moment a second marginal drive is most likely to give out (RAIDZ1 vs RAIDZ2 resilver risk), so you want your replacement done from a position of full redundancy whenever possible.
What this layer does and doesn’t do
Scrubs and SMART are health and integrity checks — they keep your pool honest and warn you before hardware quits. They are not a backup. A scrub can’t recover data the pool no longer has a good copy of, and a passing SMART test won’t save you from an accidental rm, a pool-wide corruption event, ransomware, or a fire. That’s what snapshots and off-box replication are for. Think of it as a stack: SMART and scrubs keep the disks and data verified; snapshots and replication keep you recoverable when something the disks can’t catch goes wrong. You want every layer.
Next steps
- ZFS Pool Design: RAIDZ vs Mirrors — redundancy is what lets a scrub repair corruption rather than just report it.
- TrueNAS Snapshot and Replication Strategy — the recovery layer that scrubs and SMART can’t replace.
- The TrueNAS Hardware Guide for choosing drives worth monitoring.
See also
Related across the network
- Unraid Disk Disabled: Red X Causes and Rebuild — unraidhub.com
- Replacing a Failed Disk: What zpool status Degraded Means — zfsstoragehub.com