Мониторинг дисков в минимальном NAS: S.M.A.R.T., тесты и алерты в Telegram/email

Диски выходят из строя не мгновенно. В 90% случаев отказу предшествует период деградации, который можно отследить за недели или месяцы до полной потери данных. Технология S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology) встроена в каждый современный HDD и SSD и собирает статистику ошибок чтения, переназначенных секторов, времени раскрутки шпинделя и десятков других параметров. Задача администратора - настроить автоматический сбор этих данных и получать оповещения при выходе показателей за критические пороги.

В минимальном NAS без графического интерфейса вся настройка выполняется через консоль. Пакет smartmontools даёт две утилиты: smartctl для ручной проверки и демон smartd для фонового мониторинга. После установки вы сможете запланировать короткие и длинные тесты самодиагностики, а при обнаружении проблем - отправить уведомление в Telegram или на email. Инструкция протестирована на Debian 12, Ubuntu 24.04 и CentOS Stream 9.

По данным отчётов Backblaze за 2024 год, годовая частота отказов (AFR) для HDD объёмом от 4 до 16 ТБ составляет 1,2–2,5%. Для дисков старше 5 лет показатель вырастает до 6–8%. Без мониторинга вы узнаете об отказе постфактум, когда данные уже потеряны. Настроенный smartd с алертами сокращает окно между первым сигналом деградации и заменой диска до нескольких часов.

Если вы работаете с TrueNAS, обратите внимание на отдельное руководство по настройке S.M.A.R.T. тестов и email-оповещений в TrueNAS. Для централизованного мониторинга десятков серверов подойдёт интеграция с Zabbix через smartctl и UserParameter.

Зачем нужен мониторинг дисков в NAS

S.M.A.R.T. - это стандарт самодиагностики, реализованный на уровне контроллера накопителя. Контроллер фиксирует аномалии: рост времени отклика, появление нестабильных секторов, превышение температуры. Каждый параметр имеет текущее значение (VALUE), наихудшее зарегистрированное (WORST) и порог отказа (THRESHOLD). Когда VALUE опускается до THRESHOLD, диск считается неисправным.

Минимальный NAS - это сервер без GUI, собранный на базе Debian или Ubuntu Server с программным RAID или ZFS. В такой конфигурации нет панели управления с графиком состояния дисков. Единственный способ узнать о проблеме - настроить автоматический мониторинг и оповещения. Пропуск сигнала о росте числа переназначенных секторов приводит к тому, что через 2–4 недели диск полностью отказывает, и пул ZFS теряет избыточность.

Практика показывает: диски не умирают внезапно. Анализ 200 000+ накопителей Backblaze подтверждает, что рост атрибутов 5 (Reallocated Sectors Count) и 197 (Current Pending Sector) коррелирует с отказом в ближайшие 30 дней с вероятностью 70%. Своевременный алерт даёт фору на замену без потери данных и без ночных аварийных выездов.

Установка и первичная настройка smartmontools

Пакет smartmontools доступен в репозиториях всех основных дистрибутивов. Установка занимает одну команду.

Debian / Ubuntu:

sudo apt update && sudo apt install smartmontools -y

CentOS / RHEL / Fedora:

sudo dnf install smartmontools -y

После установки проверьте, включена ли поддержка S.M.A.R.T. на целевом диске. Не все производители активируют её по умолчанию. Команда для проверки:

sudo smartctl -i /dev/sda

В выводе найдите строку SMART support is: Available - device has SMART capability. Если следом идёт SMART support is: Disabled, включите принудительно:

sudo smartctl -s on /dev/sda

Для NVMe-накопителей путь устройства отличается - /dev/nvme0n1. Команды smartctl работают с ними аналогично, но набор атрибутов специфичен.

Проверка состояния диска вручную с помощью smartctl

Общий статус здоровья диска выводится флагом -H. Это первая команда, которую стоит выполнить на новом сервере:

sudo smartctl -H /dev/sda

Результат PASSED означает, что критические атрибуты в норме. FAILED - диск необходимо заменить немедленно. Однако PASSED не гарантирует отсутствия проблем: диск может пройти проверку здоровья, но иметь 50 переназначенных секторов при пороге в 100. Поэтому всегда смотрите полную таблицу атрибутов:

sudo smartctl -A /dev/sda

Вывод содержит колонки:

ID# - номер атрибута;
ATTRIBUTE_NAME - название;
VALUE - текущее нормализованное значение (обычно от 1 до 253, чем выше - тем лучше);
WORST - наихудшее значение за историю наблюдений;
THRESHOLD - порог, при котором диск считается неисправным;
RAW_VALUE - сырое значение (количество событий, часов, секторов).

Если VALUE приближается к THRESHOLD или RAW_VALUE ненулевое для критических атрибутов - пора планировать замену.

Планирование автоматических тестов самодиагностики

Ручная проверка полезна при аудите, но мониторинг должен работать без участия человека. smartmontools поддерживает три типа тестов:

Short (короткий) - проверяет электронику, механику и выборочные участки поверхности. Длится 2–5 минут.
Long (длинный) - полное сканирование поверхности. Для HDD 8–16 ТБ занимает 12–24 часа.
Conveyance - тест на повреждения при транспортировке. Актуален только для новых дисков сразу после установки.

Рекомендуемое расписание: короткий тест ежедневно в 02:00, длинный - еженедельно в ночь с субботы на воскресенье в 03:00. Такое расписание не пересекается с пиковыми нагрузками и даёт достаточно данных для раннего обнаружения деградации.

Конфигурация демона smartd для выполнения тестов

Демон smartd читает конфигурацию из /etc/smartd.conf. Строки, начинающиеся с DEVICESCAN, применяются ко всем обнаруженным дискам. Формат директивы -s задаёт расписание тестов:

DEVICESCAN -s (S/../.././02|L/../../7/03) -m root

Разбор формата -s:

S - Short тест, L - Long тест;
Пять полей через / соответствуют: минуты (0–59), часы (0–23), день месяца (1–31), месяц (1–12), день недели (0–7, где 0 и 7 - воскресенье);
Точка . означает «любое значение»;
| разделяет несколько расписаний.

Пример выше означает: короткий тест каждый день в 02:00, длинный - каждое воскресенье в 03:00. После редактирования конфигурации перезапустите демон:

sudo systemctl restart smartd
sudo systemctl status smartd

Проверьте логи, чтобы убедиться, что тесты запускаются по расписанию:

sudo journalctl -u smartd --since "1 hour ago"

Альтернативный способ - cron. Запись в crontab:

0 2 * * * /usr/sbin/smartctl -t short /dev/sda
0 3 * * 0 /usr/sbin/smartctl -t long /dev/sda

Минус cron-подхода: он не отслеживает результаты тестов и не отправляет уведомления при ошибках. Для этого нужен smartd.

Настройка уведомлений о проблемах с дисками

Демон smartd при обнаружении проблемы выполняет действие, заданное директивой -M. Базовый синтаксис:

-m admin@example.com - отправить письмо через системный MTA;
-M exec /path/to/script.sh - выполнить скрипт, передав ему текст ошибки через стандартный ввод.

Второй вариант универсален: скрипт может отправить сообщение в Telegram, Slack или записать инцидент в систему мониторинга. Готовое решение для комплексного мониторинга с Grafana и Zabbix описано в статье про автоматический мониторинг дисков с уведомлениями в Telegram и email.

Отправка алертов в Telegram через Bot API

Telegram - самый быстрый канал для критических алертов. Настройка состоит из трёх шагов.

Шаг 1. Создание бота. В Telegram найдите @BotFather, отправьте команду /newbot, задайте имя и получите токен вида 123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11. Сохраните токен в защищённом месте.

Шаг 2. Получение chat_id. Напишите боту любое сообщение, затем выполните запрос:

curl -s "https://api.telegram.org/bot<ТОКЕН>/getUpdates" | jq '.result[0].message.chat.id'

Если jq не установлен, поставьте его через apt install jq или найдите chat_id вручную в JSON-выводе.

Шаг 3. Скрипт-обёртка. Создайте файл /usr/local/bin/smartd-telegram.sh:

#!/bin/bash
TOKEN="ВАШ_ТОКЕН"
CHAT_ID="ВАШ_CHAT_ID"
MESSAGE=$(cat)
curl -s -X POST "https://api.telegram.org/bot${TOKEN}/sendMessage" \
  -d chat_id="${CHAT_ID}" \
  -d text="SMARTd Alert%0A${MESSAGE}" \
  -d parse_mode="HTML" > /dev/null

Сделайте скрипт исполняемым:

sudo chmod +x /usr/local/bin/smartd-telegram.sh

Протестируйте вручную:

echo "Тестовое сообщение от smartd" | /usr/local/bin/smartd-telegram.sh

Если сообщение пришло, добавьте вызов скрипта в /etc/smartd.conf:

DEVICESCAN -s (S/../.././02|L/../../7/03) -M exec /usr/local/bin/smartd-telegram.sh -M test

Флаг -M test отправляет тестовое сообщение при каждом перезапуске smartd. После отладки уберите его, чтобы не засорять канал.

Настройка email-уведомлений через msmtp

Email-оповещения - резервный канал. Для отправки почты без поднятия полноценного MTA используйте лёгкий SMTP-клиент msmtp.

Установка:

sudo apt install msmtp msmtp-mta mailutils -y

Конфигурация /etc/msmtprc (пример для Gmail):

defaults
auth           on
tls            on
tls_trust_file /etc/ssl/certs/ca-certificates.crt
logfile        /var/log/msmtp.log

account        gmail
host           smtp.gmail.com
port           587
from           your-email@gmail.com
user           your-email@gmail.com
password       ваш-пароль-приложения

account default : gmail

Для Gmail требуется пароль приложения, а не основной пароль аккаунта. Создайте его в настройках безопасности Google (раздел «Пароли приложений»). Права на файл конфигурации:

sudo chmod 600 /etc/msmtprc

Проверка отправки:

echo "Тест email-оповещения" | mail -s "SMARTd Test" admin@example.com

Для интеграции со smartd используйте стандартную директиву -m. Она работает через команду mail, которую предоставляет пакет mailutils. Пример строки в /etc/smartd.conf:

DEVICESCAN -s (S/../.././02|L/../../7/03) -m admin@example.com -M test

Можно комбинировать оба канала - email и Telegram - указав две директивы -M exec или -m и -M exec одновременно.

Интерпретация S.M.A.R.T. атрибутов и принятие решений

Не все атрибуты одинаково важны. Производители дисков включают в S.M.A.R.T. десятки параметров, но только несколько из них достоверно предсказывают отказ.

Критические атрибуты для HDD:

ID	Название	Значение	Действие
5	Reallocated Sectors Count	RAW_VALUE > 0	Начать мониторинг ежедневно. При росте - замена.
197	Current Pending Sector	RAW_VALUE > 0	Немедленная замена. Сектора не читаются.
198	Offline Uncorrectable	RAW_VALUE > 0	Замена. Данные в этих секторах потеряны.
10	Spin Retry Count	RAW_VALUE > 0	Проблемы с механикой шпинделя. Замена.
187	Reported Uncorrectable Errors	RAW_VALUE > 0	Ошибки, не исправленные ECC. Замена.

Критические атрибуты для SSD:

ID	Название	Значение	Действие
177	Wear Leveling Count	VALUE < 10	Ресурс ячеек исчерпан. Планировать замену.
233	Media Wearout Indicator	VALUE < 10	Аналог Wear Leveling для некоторых вендоров.
9	Power-On Hours	Сравнить с TBW	Косвенный показатель износа.

При получении алерта о превышении порога выполните три действия. Первое: проверьте RAW_VALUE атрибута - один переназначенный сектор не критичен, но 50 и более требуют реакции. Второе: запустите длинный тест (smartctl -t long /dev/sda) и проверьте результат через smartctl -l selftest /dev/sda. Третье: если тест завершился с ошибкой Completed: read failure - немедленно замените диск.

Типовые проблемы и их решение

S.M.A.R.T. не поддерживается или отключен. Частая ситуация с USB-контейнерами и дешёвыми SATA-контроллерами. Проверьте флагом -d:

smartctl -d sat -i /dev/sdb

Для USB-дисков часто требуется указать тип устройства явно: -d sat, -d usbjmicron или -d usbprolific. Если ни один вариант не работает, мост USB-SATA не пропускает S.M.A.R.T.-команды. Решение - подключить диск напрямую к SATA-порту.

smartd не запускается. Проверьте статус и логи:

sudo journalctl -u smartd -n 50

Типичная ошибка - отсутствие прав на устройства. Убедитесь, что пользователь, от которого работает smartd (обычно root), имеет доступ к /dev/sd*. В конфигурации /etc/smartd.conf можно указать конкретные устройства вместо DEVICESCAN:

/dev/sda -s (S/../.././02|L/../../7/03) -m admin@example.com

Уведомления не приходят. Отлаживайте по цепочке. Сначала проверьте скрипт вручную: echo "test" | /usr/local/bin/smartd-telegram.sh. Если скрипт работает, проверьте, что smartd его вызывает. Включите -M test, перезапустите демон и проверьте логи. Для email - убедитесь, что msmtp отправляет почту командой echo "test" | mail -s "test" admin@example.com. Лог msmtp находится в /var/log/msmtp.log.

Ложные срабатывания на новые диски. Некоторые производители (особенно Seagate) поставляют диски с ненулевыми RAW_VALUE атрибутов 1 (Raw Read Error Rate) и 7 (Seek Error Rate). Это нормально - данные атрибуты содержат закодированную информацию, а не абсолютное число ошибок. Ориентируйтесь только на атрибуты 5, 197, 198 и результаты тестов самодиагностики.

Для тех, кто строит централизованную систему мониторинга, рекомендуем материал по настройке алертов в TrueNAS с интеграцией Telegram и Prometheus. Если часть инфраструктуры работает на Windows, пригодится обзор инструментов мониторинга HDD и SSD для Windows.

Настроенный мониторинг - это страховка от внезапной потери данных. Затраты на внедрение: 20–30 минут на установку и конфигурацию. Отдача: спокойные ночи и отсутствие аварийных восстановлений из бэкапов.