Watching disk health with smartctl, nvme smart-log, and scheduled smartd self-tests

Goal

Get an ongoing, alerting view of physical disk health on a server — SATA/SAS drives via SMART and NVMe drives via their own log page — instead of relying on the operating system to notice a drive has failed.

Prerequisites

Root access; smartmontools installed for ATA/SCSI drives; nvme-cli installed for NVMe devices; know the device paths (lsblk).

Steps

1. Check overall health quickly on a SATA/SAS device: smartctl -H /dev/sda. Per smartctl(8), -H/--health "prints the health status of the device"; a failing result means the device has already failed or predicts failure within 24 hours, per the same page, and warrants an immediate backup of any data still on it.
2. Get the full picture for triage: smartctl -a /dev/sda, which "prints all SMART information about the disk", including the attribute table, error log and self-test log.
3. For an NVMe device, smartctl -a /dev/nvme0 also works, or read the log page directly: nvme smart-log /dev/nvme0, which "retrieves the NVMe SMART log page from an NVMe device and provides the returned structure", per nvme-smart-log(1) — fields include a critical warning byte, temperature, percentage used and available spare.
4. Watch attributes that matter most: for ATA drives, reallocated/pending sector counts and end-to-end error counts rising above zero are early failure signals; for NVMe, a nonzero critical warning byte or available spare dropping toward its threshold are the equivalents.
5. Schedule recurring self-tests and reporting instead of only checking on demand: in /etc/smartd.conf (RHEL/Fedora: /etc/smartmontools/smartd.conf), a device line such as /dev/sda -a -o on -S on -s S/../.././02 -m admin@example.org -M exec /usr/local/bin/smart-alert.sh runs a short self-test every day between 2 and 3 am, matching the exact example in smartd.conf(5) for that schedule; the man page's equivalent example for a weekly long test is -s L/../../7/04 (long test, every Sunday, 4–5 am). The -s REGEXP option runs a test when the 12-character string T/MM/DD/d/HH matches the regular expression. -o/-S apply to ATA drives only; -m mail needs a working local mail transfer agent. smartd ignores every line after an uncommented DEVICESCAN, which many distributions ship by default, so comment it out or put device lines before it.
6. Enable and start smartd: systemctl enable --now smartd. Confirm it picked up the config: journalctl -u smartd -n 30.

Expected result

smartctl -H reports PASSED (or a specific failure reason); nvme smart-log returns a structure with critical_warning: 0; smartd's log shows scheduled self-tests starting at the configured times, and a test failure or an attribute crossing its threshold triggers the configured mail/exec alert.

Limits and test basis

Based on smartctl(8), smartd.conf(5) and nvme-smart-log(1). No undo is needed for read-only health checks; to stop scheduled testing, remove the device line from smartd.conf and restart smartd. A "PASSED" overall health result does not guarantee a drive will not fail soon, so treat rising attribute counts as at least as important as the summary verdict. Behind hardware RAID controllers or USB bridges, smartctl and smartd usually need a -d device type (e.g. -d megaraid,N) to reach the physical drive at all.