Monitoring Hard Drive Health with smartctl and smartd on Linux: Early Warning for Failing Disks - ITFROMZERO - Share tobe shared! A practical guide to monitoring hard drive health on Linux with smartctl and smartd, based on 6 months of real-world experience on production servers. Compare three approaches and configure automatic S.M.A.R.T. alerts to catch failing drives before it's too late.

I once lost a 4TB drive on a production server with zero warning — simply because smartd wasn’t installed at the time. Came in one morning, RAID5 was reporting degraded, pulled the logs, and found that drive had been accumulating hundreds of Reallocated Sectors for weeks. S.M.A.R.T knew the whole time — nobody thought to ask it.

That incident pushed me to properly learn smartctl and smartd. After six months running them across a dozen servers — from Dell PowerEdge machines in a data center to Vultr VPS instances with NVMe drives — here’s what actually matters.

Table of Contents

Three Ways to Monitor Drives — Not All Created Equal

Three different approaches, each suited to a different situation — picking the wrong one just wastes your time. Quick comparison:

Option 1: Running smartctl Manually

The simplest approach — run the command whenever you need it. Great for a one-time check or when you’re debugging a suspicious drive.

# View overall information
sudo smartctl -a /dev/sda

# Run short self-test (~2 minutes)
sudo smartctl -t short /dev/sda

# View self-test results
sudo smartctl -l selftest /dev/sda

Strengths: no setup required, results are immediate.
Weaknesses: you have to remember to check — and sysadmins rarely do that before something breaks.

Option 2: smartd Daemon — Automatic Alerts

smartd runs in the background, automatically polls all drives on a schedule, and sends email/syslog notifications when it spots something wrong. I deploy this on every physical server I manage.

Strengths: set-and-forget, no manual checking needed, early warning before complete failure.
Weaknesses: requires a working mail server on the host, overkill for VPS instances or containers.

Option 3: Exporter + Prometheus/Grafana

Use smartctl_exporter to expose metrics, have Prometheus scrape them, and graph everything in Grafana. Best fit if you already have a centralized monitoring stack.

Strengths: historical visualization, flexible alert rules, integrates with your overall monitoring setup.
Weaknesses: significantly more overhead, not worth it if drive monitoring is all you need.

Analysis: What Actually Matters in S.M.A.R.T?

S.M.A.R.T reports dozens of metrics, but in practice I only watch 5–6. The ones below are attributes I’ve personally seen precede real failures:

ID 5 — Reallocated_Sector_Ct: number of bad sectors that have been remapped. If this count is climbing, the drive is slowly dying. Danger threshold: > 0 on older HDDs, > 10 means replace immediately.
ID 187 — Reported_Uncorrect: sectors with uncorrectable errors. Any value > 0 is concerning.
ID 197 — Current_Pending_Sector: sectors pending re-verification — a sign that trouble is coming.
ID 198 — Offline_Uncorrectable: similar to 197 but detected during offline testing.
ID 190/194 — Temperature: drive temperature. HDDs are generally safe below 50°C, SSDs below 70°C.

Early in my sysadmin career, I once spent an entire afternoon debugging this kind of error. Convinced it was filesystem corruption from a kernel bug, I kept digging through dmesg — until I finally ran smartctl -a and saw Reallocated_Sector_Ct had climbed to 847.

Choosing the Right Approach

Physical servers, NAS, desktop machines: use smartd. Low setup cost, high payoff.
Cloud VPS (AWS, GCP, DigitalOcean): manual smartctl or skip it — hypervisors typically don’t expose full S.M.A.R.T data.
Homelab or office with multiple machines: consider the Prometheus exporter if you want a nice dashboard.
One-time check before buying or selling a used drive: smartctl -a is all you need.

Deployment: Installing and Configuring smartd

Step 1: Install smartmontools

# Debian/Ubuntu
sudo apt install smartmontools -y

# RHEL/AlmaLinux/Rocky
sudo dnf install smartmontools -y

# Arch Linux
sudo pacman -S smartmontools

Step 2: Verify Drive Detection

# List all drives
lsblk -d -o NAME,SIZE,TYPE,ROTA

# Check SMART support
sudo smartctl -i /dev/sda

# If the drive is behind a RAID controller (LSI, HP Smart Array)
# Specify the device type, for example:
sudo smartctl -d megaraid,0 -a /dev/sda

If you see SMART support is: Enabled, you’re good. If it shows Disabled:

sudo smartctl -s on /dev/sda

Step 3: Reading smartctl -a Output

sudo smartctl -a /dev/sda

The most important section is SMART Attributes Data Structure. The VALUE column is the current value — higher is better. The THRESH column is the minimum threshold set by the manufacturer. The RAW_VALUE column is the actual raw number. When VALUE drops below THRESH, the drive has officially failed by the manufacturer’s criteria.

Step 4: Configure smartd

The main configuration file is /etc/smartd.conf. This is the config I use in production:

sudo nano /etc/smartd.conf

# Monitor all ATA/SCSI drives found automatically
DEFAULTS -a -o on -S on -n standby,q \
  -s (S/../.././02|L/../../6/03) \
  -W 4,45,50 \
  -m root \
  -M exec /usr/share/smartmontools/smartd-runner

# Auto-scan all drives
DEVICESOCAN

Explanation of key options:

-a: enable all default checks
-o on: enable Automatic Offline Testing
-S on: enable Attribute Autosave
-s (S/../.././02|L/../../6/03): run a short test at 2 AM daily, long test at 3 AM on Saturdays
-W 4,45,50: alert when temperature rises 4°C, exceeds 45°C, or hits critical at 50°C
-m root: send alerts to root

To receive alerts directly instead of through root, change -m root to -m [email protected]. Remember to install postfix or msmtp so the server can send external mail.

Step 5: Start smartd

# Start and enable auto-start
sudo systemctl enable --now smartd

# Check status
sudo systemctl status smartd

# View logs
sudo journalctl -u smartd -f

Step 6: Manual Test to Confirm smartd Is Working

# Send a test email immediately
sudo smartd -d -q onecheck

# Run a short test on /dev/sdb right now
sudo smartctl -t short /dev/sdb

# Check test results (wait ~2 minutes)
sudo smartctl -l selftest /dev/sdb

Handling Real-World Scenarios

NVMe SSDs

NVMe drives don’t use the same attribute format as HDDs or SATA SSDs. Use -d nvme:

sudo smartctl -a -d nvme /dev/nvme0

For NVMe drives, pay attention to Percentage Used (how much of the drive’s lifespan has been consumed) and Available Spare (remaining spare blocks). When Available Spare drops below Available Spare Threshold, start planning a replacement.

Drives Connected via USB (Backup Drives)

# USB-SATA bridges usually need -d sat
sudo smartctl -d sat -a /dev/sdb

Quick Health Check Script for All Drives

I run this script whenever I need a quick snapshot of all drives — in 10 seconds you get a full overview without wading through pages of output:

#!/bin/bash
for disk in $(lsblk -d -n -o NAME,TYPE | awk '$2=="disk"{print $1}'); do
  echo "=== /dev/$disk ==="
  sudo smartctl -H /dev/$disk 2>/dev/null | grep -E '(overall-health|SMART overall)'
  sudo smartctl -A /dev/$disk 2>/dev/null | awk '$1 ~ /^(5|187|197|198|190|194)$/ {printf "ID%-4s %-35s %s\n", $1, $2, $NF}'
  echo
done

Clean output — just the 6 most important attributes, with raw values for immediate comparison.

Wrapping Up

S.M.A.R.T isn’t an oracle — it can’t predict 100% of drive failures. But in my experience, around 80% of failed drives showed warning signs in S.M.A.R.T days to weeks beforehand. smartd makes sure you don’t miss that window.

The whole setup takes about 15 minutes, but it can save you from a sleepless night restoring backups at 2 AM. I’m speaking from painful experience.