SMART: какие показатели реально предсказывают смерть диска

MAATRIX

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

Что такое SMART и как его вообще читать

SMART (Self-Monitoring, Analysis and Reporting Technology) — это система самодиагностики, встроенная в контроллер практически любого современного HDD и SSD. Диск сам считает статистику по десяткам параметров: сколько было ошибок чтения, сколько секторов пришлось переназначить, какая температура, сколько часов наработки — и хранит это во внутренней таблице атрибутов. Задача администратора — не гадать по ощущениям, а регулярно вытаскивать эту таблицу и следить за изменениями.

Стандартный инструмент — smartctl из пакета smartmontools, который есть в репозиториях всех основных дистрибутивов:

# Debian/Ubuntu
apt install smartmontools

# AlmaLinux/RHEL
dnf install smartmontools

Базовая проверка — полный вывод атрибутов диска:

smartctl -a /dev/sda

Ключ -a (all) выводит и общую информацию о диске (модель, серийник, прошивка), и результат последнего самотеста, и таблицу атрибутов. Если нужна только таблица атрибутов без остального — используйте -A:

smartctl -A /dev/sda

Вывод таблицы выглядит примерно так:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  9 Power_On_Hours          0x0032   095   095   000    Old_age   Always       -       19842
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0

Здесь важно понимать разницу между колонками. VALUE и WORST — это нормализованные оценки от 1 до 253 (для большинства производителей 100 или 200 — это «как новый», уменьшение говорит о деградации). THRESH — порог, ниже которого производитель считает атрибут критичным. А RAW_VALUE — сырое значение счётчика в единицах, специфичных для производителя: где-то это прямое количество событий, где-то закодированная комбинация нескольких чисел. Именно путаница вокруг RAW_VALUE — источник большинства ложных тревог, к этому вернёмся в разделе про атрибуты, которые пугают зря.

Для запуска диска на самотест (полезно перед серьёзными выводами по подозрительному диску):

smartctl -t short /dev/sda    # короткий тест, пара минут
smartctl -t long /dev/sda     # длинный тест, поверхностное сканирование, может занять часы
smartctl -l selftest /dev/sda # посмотреть результаты прошлых тестов

Reallocated Sectors Count — самый надёжный индикатор

Атрибут с ID 5 (Reallocated_Sector_Ct) — вероятно, лучший из всех, что есть в SMART для предсказания механического отказа HDD. Смысл простой: диск постоянно проверяет читаемость секторов, и если сектор оказывается физически повреждён (магнитный слой деградировал, есть царапина), контроллер помечает его как bad и подменяет ячейкой из резервной области (spare area), выделенной производителем именно для таких случаев.

Само по себе наличие небольшого количества реаллоцированных секторов не катастрофа — резервная область для того и существует. Проблема не в абсолютном числе, а в динамике: если Reallocated_Sector_Ct был 0, потом стал 3, через месяц 12, через два — 40, это устойчивый тренд деградации поверхности диска, и он практически всегда продолжается. Диски редко «останавливаются» на этом пути сами по себе.

По независимым исследованиям, которые проводили эксплуатанты крупных парков дисков (наиболее известны отчёты Backblaze, накопившей статистику по сотням тысяч дисков за годы работы), именно рост реаллоцированных секторов — один из немногих атрибутов SMART, статистически заметно повышающих вероятность отказа диска в обозримые недели-месяцы вперёд. Это не гарантия и не точный прогноз даты отказа, но сигнал, который стоит воспринимать серьёзно.

Практическое правило: если видите ненулевое и, тем более, растущее значение Reallocated_Sector_Ct на продакшн-диске — планируйте замену диска заранее, спокойно, пока он ещё работает, а не в аварийном режиме после отказа.

Current Pending Sector и Uncorrectable Sector Count

Два следующих по важности атрибута — ID 197 (Current_Pending_Sector) и ID 198 (Offline_Uncorrectable, он же в разных прошивках может называться Uncorrectable_Sector_Ct).

Current Pending Sector Count — это сектора, которые диск подозревает в проблеме, но окончательно ещё не подтвердил. Обычно это происходит так: при чтении сектора возникла ошибка, контроллер не смог сразу её исправить кодом коррекции ошибок, но и не уверен, что сектор безнадёжен — возможно, проблема временная (например, наведённая помеха). Такой сектор помечается как pending. При следующей успешной перезаписи в это место диск либо подтверждает, что сектор снова читается нормально (счётчик уменьшается), либо, если запись/чтение снова не удаётся, сектор переводится в реаллоцированные (счётчик Reallocated_Sector_Ct растёт, а Current_Pending_Sector — уменьшается).

Ненулевое значение Current_Pending_Sector — это тревожный сигнал, требующий внимания, но не обязательно немедленной паники: имеет смысл подождать несколько циклов мониторинга и посмотреть, что произойдёт дальше — уйдёт ли сектор в реаллокацию или «рассосётся».

Uncorrectable Sector Count — куда серьёзнее. Это сектора, при чтении которых механизм коррекции ошибок диска не справился вообще, и данные там гарантированно потеряны, если не было избыточности на уровне файловой системы или RAID. Рост этого счётчика — прямое свидетельство того, что диск уже сейчас теряет данные при обращении к некоторым секторам, а не просто «подозревает» проблему. Если видите растущий Uncorrectable_Sector_Ct на диске, где лежат важные данные без RAID и свежего бэкапа — это повод для немедленных действий: снять актуальную копию данных и заменить диск, а не откладывать до выходных.

Таблица-памятка по трём ключевым HDD-атрибутам:

SSD: другое железо — другие атрибуты

У SSD нет механической поверхности и головок, поэтому атрибуты про сектора либо отсутствуют, либо ведут себя иначе — вместо механической деградации там износ ячеек флеш-памяти от циклов записи (wear leveling). Подробно про то, как именно SSD стареет и почему это медленный, но неизбежный процесс, разобрано в статье про то, как SSD умирает медленно из-за wear leveling — там же про TBW (Total Bytes Written) как единицу измерения ресурса.

Для SMART-мониторинга SSD стоит смотреть на атрибуты, связанные с остатком ресурса флеш-памяти:

• SSD_Life_Left / Percent_Lifetime_Remain (обычно ID 231 или 202) — производитель сам оценивает, сколько процентов заявленного ресурса записи осталось. Значение читается напрямую: упало до 10% — пора планировать замену.
• Media_Wearout_Indicator (ID 233, часто у Intel/старых Kingston) — похожая идея, только считается по нормализованной шкале 100→1, где 1 означает почти полную выработку ресурса.
• Total_LBAs_Written / Host_Writes (ID 241 или 246 в зависимости от производителя) — суммарный объём данных, записанных на диск за всё время. Сопоставив это значение с заявленным TBW/DWPD из спецификации диска, можно прикинуть остаточный ресурс, даже если производитель не даёт готового процента.
• Wear_Leveling_Count / Erase_Fail_Count — статистика по количеству циклов стирания блоков и неудачным попыткам стирания; рост числа ошибок стирания — плохой знак, сравнимый по смыслу с реаллоцированными секторами у HDD.

Важный нюанс: в отличие от HDD, где Reallocated_Sector_Ct работает практически одинаково у всех производителей, у SSD названия и номера ID атрибутов сильно различаются между брендами и даже между линейками одного бренда. Проверяйте конкретно свою модель — часто в даташите производителя описано, что именно означает каждый нестандартный атрибут.

Атрибуты, которые пугают зря

Здесь стоит быть максимально честным: часть атрибутов регулярно вызывает панику у людей, которые впервые открыли вывод smartctl -a, хотя реальных оснований для тревоги нет.

Классический пример — Raw_Read_Error_Rate (ID 1) и Seek_Error_Rate (ID 7). У дисков Seagate RAW_VALUE этих атрибутов часто выглядит как огромное число — миллионы или даже сотни миллионов — и человек, привыкший, что растущий счётчик ошибок это плохо, приходит к выводу, что диск сыплется прямо сейчас. На деле у Seagate это упакованное значение: производитель хранит в сыром 48-битном поле сразу несколько чисел (например, количество попыток и количество реальных ошибок), и большое число само по себе ничего не говорит без знания конкретной схемы кодирования этого производителя. У других брендов (например, у части моделей Western Digital и Toshiba) те же атрибуты могут показывать честный небольшой счётчик, и там большое число действительно значимо. Вывод: нельзя интерпретировать RAW_VALUE этих двух атрибутов одинаково для всех производителей — смотрите на VALUE/WORST относительно THRESH (нормализованная оценка производителя учитывает его же собственную шкалу) и на то, меняется ли RAW_VALUE со временем, а не на голое абсолютное число при разовом просмотре.

Похожая история с Hardware_ECC_Recovered / Multi_Zone_Error_Rate — атрибуты, отражающие внутреннюю статистику коррекции ошибок на лету, которая происходит постоянно и является нормальной частью работы диска, а не признаком проблемы. Большое RAW_VALUE здесь — почти всегда норма для данной модели, а не сигнал беды.

Общее и, пожалуй, самое важное правило честного чтения SMART: важнее смотреть на динамику изменения показателя во времени, чем на разовое абсолютное значение. Одна проверка smartctl -a показывает мгновенный снимок, из которого без истории трудно сделать вывод — является ли текущее число нормой для этой конкретной модели или уже отклонением. Регулярный мониторинг с сохранением истории значений — единственный способ отличить «у этого диска так было всегда» от «этот диск начал деградировать на прошлой неделе».

Как построить мониторинг, а не разовую проверку

Ручной запуск smartctl -a время от времени лучше, чем ничего, но полноценная защита — это фоновый демон smartd, который идёт в том же пакете smartmontools и умеет проверять диски по расписанию и слать алерты при отклонениях.

Базовая настройка в /etc/smartd.conf:

# Проверять диск каждые 30 минут, слать письмо на email при проблеме,
# запускать короткий тест ежедневно в 2 часа ночи, длинный — по субботам в 3
/dev/sda -a -o on -S on -s (S/../.././02|L/../../6/03) -m admin@example.com -M exec /usr/share/smartmontools/smartd-runner

Ключи:

• -a — включить мониторинг всех поддерживаемых атрибутов;
• -o on — включить offline-тестирование (фоновая проверка поверхности без прерывания работы диска);
• -S on — сохранять атрибуты между перезапусками для сравнения истории;
• -s — расписание автотестов по cron-подобному синтаксису;
• -m — адрес для алертов.

После правки конфига:

systemctl enable --now smartd
systemctl restart smartd
journalctl -u smartd -f

Если серверов много и хочется единую картину, а не письма с десятков хостов по отдельности, разумно завести отдельный мониторинг с историей и графиками по железу — как это сделать с нуля, разобрано в статье про мониторинг диска на VPS, а более широкий обзор метрик железа, которые стоит собирать помимо SMART, — в статье про мониторинг здоровья железа.

Практический совет по порогам: не полагайтесь только на встроенный механизм TYPE=Pre-fail и WHEN_FAILED в выводе smartctl — многие диски годами продолжают работать даже после формального превышения порога производителя, а некоторые начинают сыпаться до того, как порог будет пройден. Постройте собственный алертинг по конкретным атрибутам — прежде всего по трём разобранным выше (5, 197, 198) — с алертом на любое увеличение значения, а не только на превышение порога.

Честно про ограничения предсказания

SMART — это раннее предупреждение, а не гарантия. Он умеет заранее сигнализировать о многих типах деградации: постепенном ухудшении магнитной поверхности HDD, росте ошибок чтения, выработке ресурса флеш-памяти SSD. Но есть категории отказов, которые происходят без каких-либо предварительных признаков в SMART вообще:

• Внезапный отказ электроники контроллера диска — сгорел чип, отказал источник питания на плате диска. Диск был полностью здоров по всем показателям SMART секунду назад и полностью мёртв сейчас.
• Механический удар или вибрация, повредившие головки или шпиндель у HDD — тоже происходит мгновенно, никакой постепенной деградации показателей заранее не будет.
• Прошивочные баги — отдельные партии дисков разных производителей были подвержены багам прошивки, приводившим к внезапному «зависанию» диска без всякой связи с реальным физическим состоянием носителя.

Именно поэтому SMART-мониторинг снижает, но не устраняет полностью риск внезапного отказа без предупреждения. Это дополнение к резервному копированию, а не его замена: там, где деградация постепенная, SMART даст время подготовиться и заменить диск спокойно; там, где отказ мгновенный, единственная защита — актуальная резервная копия и, для критичных сервисов, отказоустойчивая схема на уровне RAID или репликации. Если данные важны, SMART-алерты и регулярный бэкап должны работать вместе, а не по отдельности.

Частые вопросы