A passed SMART test is not a healthy disk

The word on the screen is PASSED

Take an invented example, not anyone's real server. A small home server has a data drive that has started making the odd noise. You run `smartctl -H` against it, and the answer is one word: PASSED. Do you leave it alone?

PASSED tells you less than it sounds. Know what the check asks before deciding.

What the health check measures

The smartctl manual is direct about this. For ATA drives, the `-H` health status comes from the boolean result of the SMART RETURN STATUS command. If the drive reports failing health, the manual says it has either already failed or is predicting its own failure within the next 24 hours, and you should get your data somewhere safe as soon as you can.

The manual also says that the answer can be unknown because of a layer between the disk and the operating system, naming RAID controller and USB bridge firmware. In that case smartctl prints a warning and instead checks whether any pre-failure attribute's normalised value is at or below its threshold. NVMe drives are different again: their status comes from the Critical Warning byte in the SMART/Health Information log.

Interpretation: either way, `-H` is a pass-or-fail verdict against limits the drive's maker chose. It is not a reading of how the disk is trending.

Attributes are raw counters with vendor meanings

`smartctl -A` prints the attribute table for ATA drives. The manual explains that each attribute has a raw value and a normalised value. The vendor's firmware converts raw to normalised, and the threshold is also set by the manufacturer. An attribute is said to have failed when its normalised value is less than or equal to its threshold. A Pre-fail type, on its own, does not mean the disk is about to fail.

The manual adds two warnings. Since ATA/ATAPI-4, the meaning of these attribute fields has been entirely vendor-specific, although most newer drives seem to respect it. And solid-state drives use different meanings for some attributes, so the printed name can be wrong unless the drive is in the smartmontools drive database.

Interpretation: a raw counter can climb for weeks while the normalised value stays above threshold, so the health check keeps saying PASSED. That is why the raw numbers, and how they change, are worth recording.

A self-test is a different question

A self-test is something you ask the drive to do. The manual describes a short test as usually under ten minutes and a long test as tens of minutes to several hours. Self-tests check electrical and mechanical performance as well as read performance, and their results go to a log you read with `smartctl -l selftest`. The health status is a separate verdict.

What large fleets found

Backblaze's 2016 post, by Andy Klein, describes data from 67,814 drives in one data centre, captured daily with smartmontools. At the time it used five attributes to help decide whether a drive might fail: 5 (reallocated sectors), 187 (reported uncorrectable errors), 188 (command timeout), 197 (current pending sectors) and 198 (uncorrectable sectors). A raw value above zero was a reason to investigate, not a verdict.

In that 2016 dataset, 76.7% of failed drives had one or more of those five above zero, against 4.2% of operational drives. So 23.3% of failed drives gave no warning through them. The post also says a small non-zero value can mean little on its own, that all but 197 are cumulative, and that a jump from zero to 20 in one day reads differently from the same total spread over years. Those figures belong to that fleet in 2016; they are not a current failure rate for your drive.

Pinheiro, Weber and Barroso's FAST '07 paper reaches a similar caution. Some SMART parameters correlated highly with failure, yet the authors concluded that models based on SMART parameters alone are unlikely to be useful for predicting individual drive failures.

A bounded routine

Judgment: treat SMART as a trend you watch, not a verdict you trust. Everything below is an example routine, and smartmontools is an example tool, not an endorsement.

First, make sure the data on the drive is already restorable. A backup is not a restore plan until you have restored from it.

Next, record a baseline while nothing is wrong. Run `smartctl -H -A -l selftest` against the drive (for example `/dev/sda`, as the manual's own examples use) and keep the output with the date and the drive's serial number. If the health line warns that status could not be read, note that too: it may be the enclosure or controller, not the disk.

Then schedule self-tests. The smartd.conf manual documents the `-s` directive, which matches a type and time pattern. Its examples include `-s S/../.././02` for a short test between 2 and 3 am every day, and `-s L/../../7/04` for a long test between 4 and 5 am on Sundays. The manual also shows several patterns joined in one expression with `|`.

After that, compare. On each check, look at the raw values of 5, 187, 188, 197 and 198 against the baseline and against last time, plus any new entries in the self-test log. Judgment: a counter that was stable and then jumps is the signal; a fixed small number that never moves is a note to keep watching.

When something jumps, act in order: confirm the latest backup restores, copy off anything that is not covered, then plan a replacement. Judgment: get the data safe before running more long tests to see whether it gets worse.

Limits and recovery

SMART misses failures, as the 2016 figures above show. A USB bridge or RAID controller can stand between you and the status. Attribute meanings vary by vendor, and solid-state drives can mislabel them. NVMe drives report health through a different log, and NVMe self-test support in smartctl and smartd is marked experimental in the current manuals. If you cannot read the data, record that you cannot, rather than reading silence as health. The recovery path in every case is the same: a backup you have already restored from.

What we would do next

Pick one drive on the home server. Check that its data has a restore you have tested. Save one dated baseline of `-H`, `-A` and `-l selftest` output, schedule one short and one long test, and put a recurring reminder to compare those five raw counters. Treat the next PASSED as one input, not the answer.

Sources and limits

This article synthesises the sources below into a practical explanation. It is not a security standard, legal advice, or a guarantee that guidance current at review time still applies — check the review date above against your own situation.

1. smartctl(8) manual page — smartmontools. Describes the -H health check as a boolean SMART RETURN STATUS result on ATA, which some RAID controller or USB bridge firmware can hide; explains raw, normalised and threshold attribute values as vendor-specific; and describes short and long self-tests whose results are read with -l selftest.
2. smartd.conf(5) manual page — smartmontools. Documents the -s directive for scheduling short and long self-tests with a T/MM/DD/d/HH regular expression, with worked examples, and marks NVMe self-test scheduling as an experimental smartd 7.5 feature.
3. What SMART Stats Tell Us About Hard Drives — Backblaze (Andy Klein). Published 6 October 2016. Names SMART 5, 187, 188, 197 and 198 as the stats Backblaze then used; reports that 76.7% of failed drives and 4.2% of operational drives had one or more above zero, so 23.3% of failed drives showed no warning from them; and stresses the time period over which errors appear.
4. Failure Trends in a Large Disk Drive Population — Pinheiro, Weber, Barroso. FAST '07 paper finding that some SMART parameters correlate highly with failure, while concluding that models based on SMART parameters alone are unlikely to be useful for predicting individual drive failures.

More from Server Attic

• 2026-10-22

  A restart policy is not supervision

  A restart policy brings a container back after it exits. Supervision is the separate work of noticing the repeats, limiting them, and escalating while the process is still failing.

• 2026-09-07

  When your home server clock is wrong, evidence stops lining up

  A wrong clock can scramble the apparent order of logs, move calendar jobs and make certificate checks fail. Diagnose the time source and offset before correcting it, then verify the evidence again.

• 2026-08-28

  Automate disk cleanup only after you can explain the growth

  A full disk invites a hurried deletion. A safer home-server workflow identifies the owner, growth rate, reclaimable data, retention need and recovery path before cleanup becomes automatic.