Мониторинг дисков и SMART в 2026: настройка оповещений и предотвращение отказов

Рабочий минимум для контроля состояния дисков в 2026 году собирается из четырёх частей: разовая проверка через smartctl, демон smartd с автоматическими уведомлениями, выгрузка метрик в Prometheus или Zabbix и заранее описанный порядок замены накопителя. Такой набор закрывает большую часть сценариев, когда деградация видна за дни или недели до полной потери доступа к данным.

Смотреть нужно на небольшой набор показателей. У HDD это Reallocated_Sector_Ct (ID 5), Current_Pending_Sector (ID 197), Offline_Uncorrectable (ID 198), Reported_Uncorrect (ID 187) и Command_Timeout (ID 188). У SATA SSD это остаточный ресурс и счётчики ошибок записи, у NVMe - Percentage_Used, Available_Spare, Media_Errors и Critical_Warning. Бинарный статус SMART overall-health для раннего предупреждения слишком грубый: он переключается только тогда, когда нормализованное значение атрибута падает до порога, записанного производителем, а этот порог часто равен нулю.

Дальше: пороги для ключевых атрибутов, готовые команды smartctl, конфигурация smartd, метрики для Prometheus и Zabbix и последовательность действий после тревоги. Примеры даны для Linux, Windows и TrueNAS.

Почему мониторинг SMART критичен в 2026 году

Backblaze в ежегодных отчётах Drive Stats публикует статистику по сотням тысяч накопителей. Средняя доля отказов (AFR) для парка HDD держится около 1-2% в год, но эта цифра мало говорит о предсказуемости отдельного диска. В тех же отчётах видно, что накопители с ненулевыми переназначенными и нестабильными секторами выходят из строя заметно чаще, чем диски с нулями в этих атрибутах.

Практическая разница между плановой и аварийной заменой измеряется не в цене диска. Замена по графику стоит один накопитель и полчаса работы. Отказ в продакшене приводит к деградации массива, ночному восстановлению, простою сервиса и риску потерять данные, если резервная копия отстала на сутки. Для ZFS-пула на 20 ТБ resilver идёт от нескольких часов до суток, всё это время массив работает без избыточности, а оставшиеся диски получают полную нагрузку чтения.

Состав парка в 2026 году разнородный: SATA HDD, часть из них с черепичной записью (SMR), SAS HDD в корпоративных массивах, SATA SSD на TLC и QLC, NVMe в серверах и домашних NAS. У каждого класса свой набор атрибутов. Мониторинг, настроенный только на классические ID 5 и 197, ничего не скажет о состоянии NVMe, у которого этих атрибутов нет вовсе. Обратная ситуация тоже встречается: SATA SSD отдают износ через vendor-специфичные ID, а часть потребительских моделей возвращает нули в половине полей.

Отдельная сложность: диски бывают скрыты от SMART. За RAID-контроллером LSI или Broadcom нужен доступ через smartctl -d megaraid,N, за USB-мостом часто помогает -d sat, а в виртуальной машине SMART либо отсутствует, либо описывает виртуальное устройство. Такие случаи закрывают на уровне гипервизора или утилитами производителя (storcli, perccli).

Цель мониторинга простая: получить окно от нескольких дней до нескольких недель, чтобы заказать диск, согласовать работы и обновить резервную копию. Предсказать точную дату отказа SMART не может, а обнаружить деградацию с запасом времени ему по силам.

Ключевые SMART-атрибуты для раннего выявления деградации

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

Атрибуты для HDD: Reallocated_Sector_Ct, Current_Pending_Sector и другие

Абсолютное значение атрибута почти ничего не значит без тренда. Если за сутки добавилось 10 переназначенных секторов, диск деградирует быстро, и разговор идёт о замене в течение недели. Если восемь секторов появились три года назад и с тех пор счётчик стоит на месте, диск живёт в паспортном режиме и остаётся в эксплуатации под наблюдением.

Вот как это выглядит в реальном выводе smartctl:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       8
  9 Power_On_Hours          0x0032   072   072   000    Old_age   Always       -       24810
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       2
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       2
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

Нормализованное значение VALUE равно 100, порог THRESH для атрибута 5 равен 10. Это значит, что статус overall-health переключится в FAILED только после 90 переназначений, то есть уведомление придёт, когда диск уже фактически нерабочий. RAW_VALUE 8 и 2 при живом статусе PASSED - это уже повод проверить резервные копии и заказать замену. RAW-значения занимают шестибайтовое поле, и производитель сам решает, как его кодировать: у Seagate атрибуты 1 (Raw_Read_Error_Rate) и 7 (Seek_Error_Rate) читаются нестандартно, поэтому их нельзя сравнивать с числами других вендоров.

Атрибуты для SSD и NVMe: износ и ошибки

У твердотельных накопителей логика другая. Отказ приходит не от механики, а от исчерпания ресурса ячеек и накопления ошибок записи. Набор атрибутов зависит от контроллера и протокола.

NVMe читается двумя путями: smartctl -a -d nvme /dev/nvme0 и nvme smart-log /dev/nvme0 из пакета nvme-cli. Выводы совпадают не полностью, поэтому при разборе инцидента полезно смотреть оба. У SATA SSD счётчик Total_LBAs_Written считает логические блоки, обычно по 512 байт, поэтому raw-значение умножают на 512 и получают объём в байтах. Формулы расчёта остаточного ресурса и готовые скрипты оповещений о критическом износе приведены в материале Мониторинг SSD: ключевые метрики здоровья и прогнозирование износа в 2026.

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

Базовая проверка занимает минуту и не требует ничего, кроме установленного пакета smartmontools.

smartctl --scan
smartctl -i /dev/sda
smartctl -H /dev/sda
smartctl -A /dev/sda
smartctl -a /dev/sda
smartctl -x /dev/sda
smartctl -l selftest /dev/sda
smartctl -t short /dev/sda
smartctl -t long /dev/sda
smartctl -a -d nvme /dev/nvme0
smartctl -a -d sat /dev/sdb
smartctl -a -d megaraid,5 /dev/sda

• --scan показывает все устройства, которые видит smartctl, включая диски за RAID-контроллером и NVMe.
• -i выводит модель, серийный номер, версию прошивки и поддерживаемые возможности.
• -H отдаёт только итоговый статус self-assessment.
• -A печатает таблицу атрибутов, -a добавляет информацию об устройстве и лог тестов, -x расширяет вывод журналом ошибок и деталями протокола.
• -l selftest читает лог самотестов, -t short и -t long запускают проверку.
• -d nvme, -d sat, -d megaraid,N задают тип доступа для NVMe, USB-мостов и аппаратных RAID.

Ключевые строки вывода: SMART overall-health self-assessment test result, таблица атрибутов и лог самотестов. Права нужны root или sudo, потому что smartctl обращается к устройству напрямую. В некоторых VPS и контейнерах доступ к raw-устройствам закрыт, и SMART там не читается вовсе.

Длительность тестов зависит от объёма: короткий тест на HDD занимает 1-2 минуты, длинный на диске 16-20 ТБ идёт от 20 часов. Тест не разрушает данные, но создаёт нагрузку, поэтому его ставят в ночное окно. Строка Completed without error означает, что поверхность прочитана без ошибок, а Read failure указывает на конкретные секторы и почти всегда заканчивается заменой.

Главная ловушка интерпретации: PASSED не означает, что диск здоров. Статус PASSED вместе с растущим Reallocated_Sector_Ct - это тревожный сигнал, при котором проверяют резервные копии и планируют замену.

Настройка smartd для автоматических оповещений

smartd входит в пакет smartmontools, работает как служба и периодически опрашивает диски. При изменении атрибутов, ошибках самотестов и падении нормализованных значений он пишет в syslog и отправляет уведомления. Конфигурация лежит в /etc/smartd.conf, в Debian и Ubuntu запуск дополнительно управляется файлом /etc/default/smartmontools.

Пример smartd.conf с порогами и расписанием

# Глобальные настройки для всех дисков
DEFAULT -a -o on -S on -n standby,q -s (S/../.././02|L/../../7/03) -m admin@example.com
DEFAULT -M daily

# HDD по стабильному пути устройства
/dev/disk/by-id/ata-WDC_WD40EFRX_123456 -a -d sat -W 0,60,40 -m storage@example.com

# NVMe: набор атрибутов другой, тип устройства указывается явно
/dev/nvme0 -a -d nvme -m storage@example.com

# Диск за RAID-контроллером LSI
/dev/sda -d megaraid,5 -a -m storage@example.com

# Скрипт для мессенджера вместо почты
/dev/disk/by-id/ata-Samsung_SSD_870 -a -M exec /usr/local/bin/smartd-notify.sh

• -a включает наблюдение за всеми атрибутами.
• -o on разрешает автоматические офлайн-тесты.
• -S on сохраняет атрибуты на диск, чтобы значения не терялись при перезапуске.
• -n standby,q не будит спящий диск и не пишет об этом в лог.
• -s задаёт расписание в формате T/MM/DD/d/HH, где S - короткий тест, L - длинный, а точки означают любое значение. Запись S/../.././02 запускает короткий тест ежедневно в 02:00, L/../../7/03 - длинный по воскресеньям в 03:00.
• -m указывает адрес получателя, -M выбирает метод уведомления: daily группирует сообщения, test проверяет доставку, exec запускает внешний скрипт.
• -W DIFF,INFO,CRIT настраивает чувствительность. DIFF задаёт изменение raw-значения, при котором пишется предупреждение, значение 0 отключает отслеживание изменений. INFO и CRIT задают уровни нормализованного значения для информационного и критического сообщения.
• -d sat, -d nvme, -d megaraid,N указывают тип устройства и нужны для USB-мостов, NVMe и дисков за аппаратным RAID.

Без флага -W smartd реагирует на порог THRESH, который производитель записал в паспорт атрибута. Для Reallocated_Sector_Ct он обычно равен 10, для Current_Pending_Sector может быть 0, поэтому уведомление по умолчанию приходит поздно или не приходит никогда. Пороги с малой задержкой удобнее держать во внешней системе мониторинга, где запрос фильтруется по идентификатору атрибута и порог меняется без правки конфига и перезапуска демона.

Конфигурацию проверяют до перезапуска: команда smartd -q onecheck прогоняет один цикл опроса и завершает работу, весь вывод уходит в syslog. Затем systemctl restart smartd и systemctl status smartd. Логи удобно смотреть через journalctl -u smartd -f.

Отправка уведомлений через email и мессенджеры

smartd не отправляет почту сам, он вызывает локальный MTA. На сервере без корпоративного релея ставят msmtp или ssmtp с внешним SMTP и создают sendmail-совместимую обёртку. Проверка доставки делается флагом -M test: демон отправляет тестовое сообщение и пишет результат в лог. Если письма не приходят, первым делом проверяют путь к бинарю sendmail (он отличается между дистрибутивами: /usr/sbin/sendmail, /usr/lib/sendmail) и попадание сообщений в спам.

Мессенджеры удобнее почты, потому что дежурный видит сообщение сразу. Работает это через -M exec: smartd запускает указанный скрипт и передаёт ему текст сообщения и переменные окружения SMARTD_DEVICE, SMARTD_FAILTYPE, SMARTD_SUBJECT и SMARTD_MESSAGE.

#!/bin/sh
# /usr/local/bin/smartd-notify.sh
API="${SMARTD_NOTIFY_API}"    # полный адрес вызова Bot API, хранится в файле с правами 600
CHAT="${SMARTD_NOTIFY_CHAT}"
TEXT="${SMARTD_SUBJECT}: ${SMARTD_MESSAGE}"
curl -s -X POST "$API" \
  --data-urlencode "chat_id=${CHAT}" \
  --data-urlencode "text=${TEXT}" >/dev/null
exit 0

Скрипт обязан завершаться с кодом 0, иначе smartd запишет ошибку и продолжит работу. Токен и адрес вызова хранят в EnvironmentFile с правами 600 или в файле, недоступном другим пользователям. Тот же механизм подходит для PagerDuty, Mattermost, Rocket.Chat и любого HTTP-API.

Если инфраструктура уже собирает журналы, есть второй путь: не слать уведомления из smartd, а забирать syslog через promtail, vector или fluent-bit и строить правила в Loki. Тогда события SMARTD приходят в тот же канал, где живут остальные алерты.

Проверить всю цепочку без риска для продакшена удобно на отдельном стенде: его поднимают за несколько минут на VPS, например в облаке Timeweb Cloud, прогоняют тестовые события через -M test и только потом переносят конфиг на рабочие серверы.

Интеграция SMART с системами мониторинга

Почта и мессенджер решают задачу оповещения, но не дают истории и трендов. Метрики SMART нужны, чтобы видеть скорость роста атрибутов, строить графики и держать пороги в одном месте с остальными алертами.

Настройка smartctl_exporter для Prometheus

smartctl_exporter запускается как отдельная служба, сам вызывает smartctl и отдаёт метрики на порту 9633. Юнит systemd выглядит так:

[Unit]
Description=SMART exporter
After=network.target

[Service]
Type=simple
User=root
ExecStart=/usr/local/bin/smartctl_exporter --web.listen-address=:9633
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

Службе нужны права root, иначе smartctl не получит доступ к устройствам. Задание в prometheus.yml:

scrape_configs:
  - job_name: smartctl
    scrape_interval: 60s
    static_configs:
      - targets: ['nas-01:9633', 'db-01:9633']

Основные метрики: smartctl_device_smart_status (1 означает PASSED), smartctl_device_health, smartctl_device_temperature, smartctl_device_media_errors, smartctl_device_percentage_used и smartctl_device_attribute с метками attribute_id, attribute_name, attribute_value и attribute_raw. Полный список смотрят на /metrics: набор метрик немного отличается между версиями экспортёра.

Правила алертинга опираются на raw-значения и на скорость изменения:

- alert: DiskReallocatedSectors
  expr: smartctl_device_attribute{attribute_name="Reallocated_Sector_Ct"} > 0
  for: 10m
  labels: {severity: warning}

- alert: DiskPendingSectorsGrowing
  expr: increase(smartctl_device_attribute{attribute_name="Current_Pending_Sector"}[6h]) > 0
  for: 5m
  labels: {severity: critical}

- alert: NvmeWearHigh
  expr: smartctl_device_percentage_used > 80
  for: 1h
  labels: {severity: warning}

Alertmanager отправляет эти события в тот же Telegram-бот или в дежурный канал. В Grafana тренды атрибутов строят по smartctl_device_attribute с фильтром по attribute_name: график роста Reallocated_Sector_Ct за 30 дней показывает динамику нагляднее любого статичного порога. Расширенный набор метрик для накопителей, включая latency, IOPS и заполнение пулов, разобран в статье Мониторинг систем хранения: ключевые метрики и инструменты для администратора.

Использование Zabbix для мониторинга SMART

Zabbix agent 2 умеет работать с SMART через встроенный плагин, отдельный экспортёр не нужен. В конфигурации агента включают плагин и путь к smartctl:

Plugins.Smart.Path=/usr/sbin/smartctl
Plugins.Smart.Timeout=30

Плагин вызывает smartctl, поэтому агенту нужны права root или настроенный sudo для пользователя zabbix, а ключи вида smart.* добавляют в белый список AllowKey. Дальше импортируют штатный шаблон SMART by Zabbix agent 2 (есть версии для Linux и Windows), который сам находит диски через низкоуровневое обнаружение и создаёт элементы по каждому атрибуту.

Триггеры, которые стоит проверить после импорта: Current_Pending_Sector больше 0, рост Reallocated_Sector_Ct за сутки, температура выше 50 °C, остаточный ресурс SSD ниже 10% и переход статуса диска в FAILED. Автообнаружение подхватывает и NVMe, если smartctl версии 7.x и выше умеет читать устройство через -d nvme. Готовые шаги по подключению, включая создание UserParameter и настройку алертов на критические атрибуты, собраны в руководстве Мониторинг SMART-дисков в Zabbix: полная инструкция по настройке.

Обоснование порогов срабатывания: как не пропустить отказ

Универсальных чисел не существует: порог зависит от класса диска, возраста, роли в массиве и от того, есть ли свежая резервная копия. Работает комбинация из трёх правил: абсолютный порог, скорость роста и контекст.

Абсолютные значения не работают в одиночку. У диска с наработкой 60 000 часов и восемью переназначенными секторами, появившимися три года назад, риск ниже, чем у нового диска, где за сутки появилось двадцать. Решение принимают по тренду. Простой способ: сравнивать значение атрибута с тем, что было неделю назад, и алертить на прирост. В PromQL это делает increase() или delta() по окну, в Zabbix - триггер по функции изменения за 7 дней, в smartd - контроль изменения raw-значения через -W.

Базовая линия обязательна. Снимок атрибутов при вводе диска в работу (smartctl -A) сохраняют рядом с серийным номером. Через год сравнение с этим снимком отвечает на вопрос, деградирует диск или просто накопил статистику.

Ложные срабатывания тоже нужно разбирать. Растущий UDMA_CRC_Error_Count чаще говорит о кабеле, бэкплейне или контроллере, чем о диске. Сезонный рост температуры летом не требует замены, достаточно проверить продувку корпуса. У Seagate raw-значения атрибутов 1 и 7 кодируются нестандартно, и попытка читать их как обычные числа даёт бессмысленный результат.

Предотвращение отказов и планирование замены

Порядок действий после тревоги определяет, закончится история плановой заменой или ночным восстановлением.

1. Проверить резервные копии и их свежесть. Снапшоты ZFS на том же пуле не защищают от отказа массива, нужна внешняя копия, восстановление из которой хотя бы раз проверяли.
2. Оценить состояние массива: zpool status -x, zpool status -v, счётчики ошибок пула, вывод dmesg за последние сутки по строкам I/O error, ata, nvme.
3. Запустить длинный самотест smartctl -t long и дождаться результата в логе. Для HDD это часы, для SSD обычно минуты.
4. Отделить проблемы интерфейса от проблем поверхности. Рост CRC без pending и reallocated лечится заменой кабеля, а не диска.
5. Проверить избыточность. Пул из одного диска, RAID 0 и массив на одном диске-паритете с накопленными ошибками переходят в опасную зону, замена становится срочной.
6. Спланировать замену: подготовить диск, окно работ и ответственного. В ZFS новый диск подключают и выполняют zpool replace, старый остаётся в системе до успешного завершения resilver.
7. Не вынимать второй диск до окончания восстановления, два rebuild подряд резко повышают риск потери массива.
8. После замены выполнить scrub, убедиться, что счётчики ошибок пула сброшены, и вернуть диск в мониторинг с обновлённой базовой линией.

Для TrueNAS шаги те же, но часть выполняется в интерфейсе: диск переводят в Offline в разделе Storage, физически меняют и запускают Replace. Перед любыми действиями проверяют, что алерты о статусе пула и S.M.A.R.T. действительно доходят до администратора.

Диск с ненулевыми Current_Pending_Sector может отказать в любой момент. Откладывать его замену на следующий квартал опасно: нестабильные секторы превращаются в нечитаемые при первой записи, а во время resilver ZFS читает всю поверхность целиком, и именно тогда ошибки проявляются массово. Наличие горячего резерва сокращает окно незащищённости с часов до минут.

Особенности мониторинга в Linux, Windows и TrueNAS

Linux: smartd и systemd

Пакет ставится штатным менеджером (apt install smartmontools, dnf install smartmontools), служба включается командой systemctl enable --now smartd. В Debian и Ubuntu автозапуск дополнительно управляется переменной start_smartd в /etc/default/smartmontools, а параметры командной строки задаются в smartd_opts. Конфигурация лежит в /etc/smartd.conf.

Вместо /dev/sdX в конфиге указывают стабильные пути /dev/disk/by-id/ata-... и /dev/disk/by-id/nvme-..., иначе после перестановки дисков или замены контроллера адреса меняются и мониторинг начинает следить не за тем устройством. Для NVMe дополнительно ставят nvme-cli и сверяют вывод nvme smart-log с данными smartctl. Полная инструкция с готовыми шаблонами конфигураций для серверных сценариев собрана в статье Мониторинг SMART в Linux: полное руководство по настройке, анализу и оповещениям.

Windows: CrystalDiskInfo и smartmontools

На рабочих станциях и серверах Windows быстрый путь даёт CrystalDiskInfo: утилита читает SMART через ATA passthrough, поддерживает NVMe, показывает атрибуты и статус диска, умеет отправлять письма при смене статуса и запускаться вместе с системой. Для автоматизации в планировщик задач ставят smartctl.exe из сборки smartmontools для Windows: smartctl -a /dev/sdX, для NVMe smartctl -a -d nvme /dev/nvme0. Обёртка на PowerShell разбирает вывод, сравнивает значения с сохранённым снимком и отправляет результат в почту или в webhook.

На Windows Server есть отдельный источник данных: Get-PhysicalDisk в связке с Get-StorageReliabilityCounter возвращает температуру, наработку, число некорректированных ошибок чтения и записи, износ (Wear) и количество переназначенных секторов. Это избавляет от разбора текстового вывода smartctl в скриптах.

TrueNAS: встроенные S.M.A.R.T. тесты и оповещения

В TrueNAS периодические тесты настраивают в интерфейсе: раздел Storage, затем Disks и подраздел S.M.A.R.T. Tests, где задаётся тип теста, расписание и набор дисков. Атрибуты смотрят там же, кнопкой S.M.A.R.T. Attributes, либо в разделе Reporting. Оповещения настраивают в System и Alert Settings: критичные события по дискам, статусу пула, температуре и состоянию ZFS приходят на почту или через Alert Services (Slack, Telegram, webhook, PagerDuty).

TrueNAS SCALE построен на Linux, внутри работает smartd, а конфигурацию генерирует веб-интерфейс, поэтому ручные правки /etc/smartd.conf перезаписываются. В TrueNAS CORE на базе FreeBSD конфигурация живёт по пути /usr/local/etc/smartd.conf, логи идут в /var/log/messages, а поддержка NVMe ограничена возможностями версии smartmontools. Отдельный слой оповещений даёт ZFS Event Daemon: он сообщает о деградации пула, ошибках чтения и записи и о проблемах с устройствами. Подробный разбор интерпретации атрибутов и настройки email-уведомлений приведён в статье Настройка и интерпретация S.M.A.R.T. мониторинга в TrueNAS.

Общее ограничение для всех платформ: в виртуальной машине SMART либо недоступен, либо описывает виртуальный диск. Тогда мониторинг переносят на гипервизор и следят за физическими накопителями средствами платформы.

Типичные ошибки и возражения при настройке мониторинга

Три возражения встречаются чаще остальных, и на каждое есть практический ответ.

Инструкция не для моей версии. Синтаксис smartctl и smartd стабилен много лет, базовые команды работают одинаково в smartmontools 7.0 и в актуальных сборках 2026 года. Отличия касаются мелочей: путь к sendmail, имя журнала (syslog или journald), поддержка новых ключей -d для NVMe. В TrueNAS конфигурацию генерирует интерфейс, в Zabbix набор элементов зависит от версии шаблона, но принцип «атрибут плюс порог плюс тренд» не меняется.

Это слишком сложно. Базовая настройка занимает 10-15 минут: установить smartmontools, проверить smartctl -a, добавить одну строку в smartd.conf с адресом почты, перезапустить службу и убедиться, что -M test дошёл.

Я уже видел подобное, и оно не работало. Частые причины: не настроен MTA и письма не уходят; сообщения попадают в спам; у агента Zabbix нет прав на smartctl; в конфиге указан /dev/sda, который после перезагрузки стал /dev/sdb; пороги выставлены по THRESH, а он равен нулю. Каждый пункт проверяется за минуту.

Список ошибок, которые ломают мониторинг:

• Ориентир на статус PASSED и игнорирование raw-значений.
• Пороги по нормализованным значениям без учёта порога производителя.
• Отсутствие проверки доставки уведомлений.
• Мониторинг только HDD, при этом NVMe и SSD остаются без контроля.
• Указание /dev/sdX вместо стабильных путей /dev/disk/by-id.
• Нет базовой линии, поэтому рост атрибута не с чем сравнить.
• Алерты настроены, но нет владельца и регламента действий.
• Нет запасного диска на складе, поэтому реакция растягивается на недели.

Чек-лист готовности: снимок smartctl -a сделан по каждому диску, базовая линия сохранена, smartd запущен и проверен через onecheck, тестовое уведомление дошло до дежурного, пороги пересмотрены, NVMe и диски за RAID подключены, бэкапы проверены восстановлением, регламент замены описан.

Заключение: начните мониторинг сегодня

Начните с одного сервера и одного диска: smartctl -a покажет текущее состояние, снимок атрибутов станет базовой линией, строка в smartd.conf даст уведомления. Дальше подключаются метрики в Prometheus или Zabbix, и вместе с ними приходят тренды, по которым видна скорость деградации.

Конечная цель не графики, а окно времени на спокойную замену диска. Когда алерт приходит за недели до отказа, замена превращается в плановую работу на полчаса вместо ночного восстановления массива и разбора последствий. Следующий шаг простой: откройте консоль, выполните smartctl -a на самом нагруженном диске и сохраните вывод как точку отсчёта.