Как понять, когда менять диск по SMART

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

Самая опасная ошибка администратора выглядит вполне рационально: увидеть предупреждение, запустить долгий тест или полную перезапись и только потом заняться копией. Если данные нужны, порядок обратный. Сначала прекращают лишнюю запись, сохраняют доступные данные и только затем уточняют диагноз. Ни один зеленый статус SMART не отменяет резервную копию, а RAID не превращает больной диск в исправный.

Немедленная замена начинается с четырех сигналов

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

Для HDD и SATA SSD я использую четыре группы красных сигналов:

• SMART overall-health self-assessment test result: FAILED или SMART Health Status: BAD;
• ненулевой и растущий Current_Pending_Sector либо Offline_Uncorrectable вместе с ошибками чтения;
• запись Completed: read failure в журнале самотестов;
• повторяющиеся I/O errors, зависания команд или исчезновение диска, которые совпадают с ошибками самого носителя.

Для NVMe главный красный флаг называется critical_warning. Биты degraded reliability и read-only прямо говорят, что подсистема потеряла надежность или перевела весь носитель в режим только чтения. Падение available_spare ниже заданного производителем порога тоже выставляет критический бит. В сервере такой накопитель выводят из эксплуатации, даже если приложения пока читают большую часть данных.

Есть важная оговорка: единичный переназначенный сектор без роста и без других ошибок не доказывает скорый отказ конкретного HDD. В домашнем вторичном хранилище за ним иногда наблюдают. В продуктивном сервере с понятным окном обслуживания я все равно планирую замену, потому что стоимость повторной диагностики и деградации массива часто выше цены диска. Срочность определяет сочетание текущей ошибки, динамики и роли накопителя.

Смотрите на RAW, VALUE и историю отдельно

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

В типичном ATA-отчете VALUE начинается около 100 или 200 и обычно уменьшается по мере ухудшения. WORST хранит худшее нормализованное значение, а THRESH задает границу, после которой атрибут считается проваленным. RAW_VALUE показывает внутренний счетчик, но его формат выбирает производитель. Число 100 в VALUE не означает здоровье на 100 процентов, а большое число в RAW_VALUE не всегда означает сотни физических ошибок.

Особенно заметно это на Raw_Read_Error_Rate и Seek_Error_Rate. Некоторые модели кодируют в сыром поле несколько величин или считают огромное число успешных операций вместе с ошибками. Seagate в собственной справке прямо предупреждает, что значения отдельных атрибутов и пороги фирменные, а сторонняя программа может трактовать их непоследовательно. Поэтому нельзя переносить порог из случайной таблицы на другую модель.

Столбец WHEN_FAILED тоже часто читают неправильно. Пустое поле не обещает, что диск исправен, оно лишь говорит, что нормализованный атрибут не пересек фирменный порог. SMART может показывать PASSED, хотя в журнале уже есть ошибка чтения или несколько ожидающих секторов. Код smartmontools специально различает общий провал статуса, атрибут ниже порога, ошибки в error log и ошибки в self-test log.

История важнее одиночного снимка. Сохраните модель, серийный номер, время работы, все атрибуты и журнал тестов, затем сравнивайте тот же диск с самим собой. Сравнивать RAW между разными семействами дисков можно лишь после проверки документации производителя. Если вчера Current_Pending_Sector был 0, сегодня стал 1, а после обычного чтения вырос до 8, это активное разрушение поверхности, хотя нормализованный VALUE может выглядеть благополучно.

Для HDD опасны ожидающие и неисправимые сектора

На магнитном диске наиболее полезны атрибуты 5, 187, 197 и 198, но каждый описывает отдельную стадию отказа. Считать их взаимозаменяемыми нельзя.

Reallocated_Sector_Ct (5) показывает, сколько плохих физических секторов накопитель уже заменил резервными. Данные в логическом адресе снова могут читаться нормально, поэтому это исторический след, а не обязательно текущая ошибка. Один стабильный переназначенный сектор требует наблюдения. Быстрый рост, новые ошибки чтения или сокращение нормализованного запаса требуют замены.

Current_Pending_Sector (197) опаснее: диск не смог уверенно прочитать сектор и пока держит его в ожидании решения. Следующая успешная запись может подтвердить сектор как рабочий или заставить прошивку переназначить его. До этого момента данные из данного LBA могут быть недоступны. Ненулевой 197 на диске с единственной копией данных означает сначала копирование всего читаемого, а не попытку «обнулить pending».

Offline_Uncorrectable (198) считает области, которые накопитель не исправил во время фонового сканирования или самотеста. Если 198 ненулевой и журнал содержит read failure, носитель уже предъявил воспроизводимую проблему чтения. Я не оставляю такой HDD в рабочем массиве после восстановления его формального статуса.

Reported_Uncorrect (187) фиксирует ошибки, которые накопитель не смог исправить и сообщил хосту. Command_Timeout (188) отмечает прерванные по тайм-ауту команды, но его надо сверять с питанием, контроллером и моделью. Backblaze выбрала атрибуты 5, 187, 188, 197 и 198 для расследования потенциальных отказов в своей большой парке HDD. Это полезный эмпирический фильтр, но не универсальная гарантия: их политика рассчитана на массивы, где диск можно заменить без потери единственной копии.

Исследование Google «Failure Trends in a Large Disk Drive Population» дает более неприятный вывод. Переназначения, ошибки сканирования и ожидающие сектора хорошо коррелировали с отказами, однако многие умершие диски не показали ни одного из сильных сигналов. SMART хорошо подтверждает риск, когда счетчики загорелись, но плохо доказывает отсутствие риска, когда все нули.

У NVMe свои признаки конца ресурса

У NVMe не надо искать привычные HDD-атрибуты по номерам. Стандарт задает общую страницу SMART / Health Information, где состояния описаны понятнее: critical_warning, available_spare, available_spare_threshold, percentage_used, media_errors и журнал ошибок.

Спецификация NVM Express 2.0 определяет отдельные биты critical_warning. Бит 0 означает, что доступный резерв упал ниже порога; бит 1 сообщает о выходе температуры за заданную границу; бит 2 отмечает ухудшение надежности из-за серьезных ошибок носителя или внутренней ошибки; бит 3 говорит, что весь носитель переведен в режим только чтения. Для устройств с резервным питанием и persistent memory предусмотрены еще два состояния.

Не все биты равны по срочности. Read-only и degraded reliability требуют немедленного вывода накопителя из записи и замены. Spare below threshold означает исчерпание резерва до уровня, который сам производитель считает критическим, поэтому ждать следующего предупреждения неразумно. Температурный бит сначала требует устранить охлаждение и снизить нагрузку, но повторное появление после нормализации температуры уже указывает на проблему самого устройства или датчика.

percentage_used показывает оценку израсходованного ресурса, сделанную прошивкой на основе ожидаемой выносливости. Значение 100 не означает, что накопитель выключится в ту же минуту, и некоторые устройства допускают числа выше 100. Оно означает, что расчетный ресурс записи исчерпан. Для продуктивной системы это граница плановой замены, а при одновременных media_errors, critical warning или ошибках приложений замена становится срочной.

media_errors считает необработанные ошибки целостности, включая неисправимые ECC, сбой CRC внутри описанного стандартом пути или несовпадение LBA tag. Один старый счетчик после известного события нельзя оценивать без error log и динамики. Новый рост во время обычной нагрузки, особенно вместе с critical warning, нельзя списывать на возраст. unsafe_shutdowns, напротив, показывает потерю питания без штатного уведомления о выключении. Он объясняет условия эксплуатации, но сам по себе не доказывает износ NAND.

Кабель и температура не равны повреждению носителя

Счетчики интерфейса, питания и температуры требуют ремонта тракта, а не автоматической утилизации диска. Их ценность в том, что они помогают не заменить исправный накопитель и оставить настоящий дефект в сервере.

UDMA_CRC_Error_Count (199) у SATA обычно растет, когда данные повреждаются при передаче между накопителем и контроллером. Частые причины находятся в кабеле, разъеме, корзине, питании или порте. Старое ненулевое значение не обнуляется после замены кабеля. Запишите его, переставьте или замените тракт и следите, увеличивается ли RAW. Если счетчик остановился, сам носитель мог быть исправен. Если одновременно растут 197 и 198, одной заменой кабеля диагноз уже не закрыть.

Высокая температура требует действий, но универсального числа для всех моделей нет. У NVMe сравнивайте текущую температуру с warning и critical threshold из Identify Controller. У SATA смотрите справочник и паспорт конкретной модели, а также историю в той же корзине. Резкий скачок одного диска при нормальных соседях подозрительнее, чем одинаковое повышение у всего ряда после отказа вентилятора.

Power_On_Hours, Power_Cycle_Count, Start_Stop_Count и Load_Cycle_Count описывают возраст и режим работы. Большое число часов помогает планировать обновление парка, но не создает моментальный приговор. То же относится к Wear_Leveling_Count и фирменным показателям life remaining у SATA SSD: название и направление шкалы надо проверить по документации модели.

Счетчик ошибок интерфейса нельзя игнорировать только потому, что он «не про диск». Плохой разъем способен вызвать зависания, выброс диска из RAID и повреждение незавершенной записи. Решение просто отличается: сохранить данные, исправить кабель, питание или backplane, затем повторно проверить динамику. Замена накопителя без ремонта тракта часто приводит к тем же симптомам на новом устройстве.

Решение принимает сочетание статуса и динамики

Один снимок SMART дает основание для действия только при явном провале. Во всех остальных случаях решение строится по текущему влиянию на данные, росту счетчиков и роли диска.

• Общий статус FAILED или BAD: прошивка пересекла собственный порог отказа. Снимите нагрузку, скопируйте доступное и замените диск немедленно.
• NVMe critical warning с read-only или reliability degraded: контроллер признал потерю надежности. Не возвращайте запись и меняйте накопитель.
• Атрибут 197 или 198 растет, а self-test дал read failure: есть активная нечитаемая область. Копируйте до тестов, затем меняйте диск.
• Атрибут 5 больше нуля, стабилен, других ошибок нет: накопитель уже переназначал область. Усильте наблюдение, для критичной роли запланируйте замену.
• Атрибут 199 растет без media errors: ошибка тракта SATA вероятнее дефекта поверхности. Исправьте кабель, порт, корзину или питание и повторите замер.

Есть ситуации, когда таблица намеренно консервативна. Диск с одной копией бухгалтерской базы надо перестать мучить раньше, чем диск с еще одной репликой и проверенной резервной копией. В RAID после отказа одного элемента оставшиеся диски получают тяжелое чтение при rebuild, поэтому несколько pending-секторов на одном из них опаснее, чем на отдельном архивном носителе.

Я не использую правило «заменять после десяти bad sectors». У него нет общей технической основы: емкость сектора, резерв прошивки, модель, скорость роста и характер ошибок различаются. Ноль не гарантирует жизнь, а выбранное круглое число не делает риск управляемым. Для активных pending и uncorrectable важен сам факт недоступных данных; для reallocated важнее тренд и контекст.

Представьте зеркало из двух HDD. На первом накопителе массив уже показывает failed, а у второго появились два pending-сектора. Автоматический rebuild на новый диск начнет последовательное чтение второго накопителя и почти наверняка дойдет до подозрительной области. Если единственная резервная копия не проверена, бездумная кнопка rebuild превращает управляемую деградацию в гонку между чтением и новой ошибкой. Сначала надо подтвердить копию, сохранить незаменимые данные и понять, с какого источника они еще читаются.

Приоритет копирования тоже зависит от ошибки. Если каталог открывается, но большие архивы дают I/O error, сначала забирайте небольшие уникальные документы и метаданные приложения, затем объемные восстанавливаемые данные. Многократное чтение одного плохого файла задерживает все остальное. Инструменты наподобие ddrescue ведут карту прочитанных и пропущенных областей, поэтому могут сначала собрать легкую часть образа, а к сложным блокам вернуться позже. Это не ремонт диска, а управление числом повторных обращений.

Сначала спасайте данные, потом проверяйте поверхность

При красном сигнале правильный порядок уменьшает число чтений с больного носителя и сохраняет шанс извлечь самые нужные файлы. Диагностика не должна конкурировать с эвакуацией данных.

1. Остановите приложения, индексацию, дефрагментацию, scrub и задачи, которые пишут на диск. Если отказ затронул массив, действуйте по процедуре хранения, а не выдергивайте устройство наугад.
2. Зафиксируйте полный SMART-отчет, журнал ядра, модель, серийный номер, слот и время события. Не тратьте на это часы, если диск уже пропадает.
3. Скопируйте наиболее важные и уникальные данные на исправное хранилище. При нестабильном чтении используйте инструмент образа, который умеет пропускать плохие области и возвращаться к ним, вместо обычного копирования с бесконечными повторами.
4. Проверьте полученную копию: откройте критичные файлы, сверьте известные хеши, запустите проверку приложения или базы на копии.
5. Замените накопитель, восстановите резервирование и только после этого исследуйте снятый диск, если анализ еще нужен.

Популярный совет записать нули в pending-сектор действительно может заставить прошивку либо принять сектор, либо переназначить его. Именно поэтому он опасен до копирования: запись уничтожает прежнее содержимое LBA и меняет улику. После успешного восстановления такая операция годится для лабораторной проверки, но не возвращает доверие к диску, который уже дал неисправимую ошибку в продуктивной работе.

Долгий SMART self-test в основном читает поверхность внутри накопителя и полезен на стабильном диске. На диске, который щелкает, отваливается или резко наращивает pending, этот тест создает дополнительную работу и задерживает копирование. Если данные незаменимы и обычное чтение ухудшает состояние, прекратите самостоятельные эксперименты и передайте носитель специалистам по восстановлению.

Полный отчет важнее цветного индикатора

Для первичной проверки нужен полный текстовый отчет, а не только зеленая галочка графической утилиты. smartctl показывает общий статус, атрибуты, журналы ошибок и самотестов; для NVMe ту же страницу здоровья может вывести nvme-cli.

sudo smartctl -x /dev/sdX
sudo smartctl -l selftest /dev/sdX
sudo smartctl -x -j /dev/sdX > smart-sdX.json

sudo nvme smart-log /dev/nvme0
sudo smartctl -x -j /dev/nvme0 > smart-nvme0.json

В хорошем базовом снимке для ATA надо сохранить строки SMART overall-health, таблицу атрибутов, SMART Error Log и SMART Self-test log. Для NVMe нужны как минимум critical_warning, available_spare, available_spare_threshold, percentage_used, media_errors, num_err_log_entries, температура и время в опасных температурных состояниях. JSON удобен для мониторинга, потому что не приходится разбирать выровненные пробелами столбцы.

Короткий самотест можно запускать после резервного копирования, если диск стабильно доступен. Команда smartctl -t short /dev/sdX обычно лишь ставит тест в очередь; результат надо позже прочитать через smartctl -l selftest /dev/sdX. Для полного чтения используют -t long, а ожидаемое время утилита сообщает в ответе. Отсутствие ошибок в коротком тесте не проверяет всю поверхность.

У smartctl код возврата представляет битовую маску, а не обычное «0 или 1». В документации smartmontools бит 3 означает провал общего SMART status, бит 4 сообщает о текущем prefail-атрибуте ниже порога, бит 6 указывает на записи в error log, бит 7 на ошибки в self-test log. Скрипт, который проверяет только exit_code == 1, пропустит серьезные состояния. Сначала сохраните JSON и код возврата, затем разберите нужные биты с учетом типа устройства.

Контроллер RAID или USB-мост может скрывать SMART либо требовать параметр типа устройства. Если smartctl не видит накопитель за HBA, это не доказывает здоровье. Запросите данные через поддерживаемый интерфейс контроллера или его BMC, сопоставьте логический диск с физическим слотом и не меняйте устройство по одному лишь имени /dev/sdX, которое могло измениться после перезагрузки.

Журнал ATA error log надо читать вместе со временем работы и типом команды. Старая запись могла возникнуть до замены кабеля и остаться навсегда, а свежая UNC-ошибка по тому же LBA подтверждает проблему чтения. Самотест с пометкой Interrupted (host reset) не равен Completed: read failure: первый мог оборваться из-за перезагрузки, режима сна или команды контроллера. Повторять его имеет смысл только после выяснения причины сброса и защиты данных.

У NVMe num_err_log_entries тоже не означает число потерянных файлов. Это количество записей в журнале ошибок контроллера, куда могут попадать разные статусы команд. Для решения нужны сами записи, media_errors, critical warning и события ОС. Если счетчик растет из-за неверных административных команд утилиты, замена не нужна; если новые записи совпадают с I/O error и media error, откладывать ее нельзя.

Мониторинг должен ловить переход, а не красивое число

Полезное оповещение фиксирует новый риск и его скорость, а не рассылает ежедневный список старых счетчиков. Для каждого серийного номера храните исходный снимок и последнее значение. Отдельно отмечайте первое появление pending, uncorrectable, media error, failed self-test и любого critical warning.

Для HDD разумная политика эскалации выглядит так: общий FAILED, новый self-test read failure и рост 197 или 198 создают аварийное событие; новый 5 создает предупреждение и заявку на проверку; рост 199 отправляет задачу на проверку тракта. Порог для плановой замены по 5 зависит от роли, но повторный рост после первого события уже нельзя считать случайной старой отметкой.

Для NVMe аварийное событие создают биты reliability degraded, read-only и spare below threshold. percentage_used лучше предупреждать заранее по внутренней политике закупки и срокам поставки, а не впервые в 100 процентов. Температурное событие должно содержать текущую величину, пороги контроллера, длительность перегрева и состояние соседних устройств. Так дежурный увидит разницу между отказом вентилятора и одним горячим накопителем.

Проверяйте сам мониторинг на исправном тестовом устройстве. Я не раз видел конфигурации, которые месяцами собирали smartctl, но теряли код возврата, не читали self-test log или после обновления меняли имя поля. Пустой график в такой системе означает поломку сбора, а не отсутствие ошибок.

SMART также не заменяет наблюдение за ОС. Тайм-ауты блочного слоя, сбросы контроллера, рост задержки, read-only файловая система и деградация RAID могут появиться раньше понятного атрибута. Событие приложения и состояние носителя надо собирать на одной временной шкале. Тогда видно, что случилось первым: перегрев, ошибка интерфейса, повреждение носителя или потеря питания.

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

Новый диск решает проблему носителя, но не исправляет плохой backplane, перегрев стойки или отсутствие проверенной копии. После восстановления избыточности сравните SMART соседних устройств, журналы контроллера и температуру в том же слоте. Если CRC и сбросы переехали на новый накопитель, причина осталась в тракте.

В организации полезно записывать не только «диск заменен», но и основание: общий FAILED, рост pending, провал self-test, NVMe critical warning, интерфейсная ошибка или профилактика по ресурсу. Такая классификация показывает, какие отказы действительно предупреждал SMART и сколько замен оказались следствием кабеля либо охлаждения. Она также помогает выбрать запас накопителей и реальное окно обслуживания без выдуманного универсального порога.

Для серверов GSE.kz диагностику накопителей имеет смысл связывать с 24/7 технической поддержкой и данными конкретной конфигурации, включая контроллер, корзину и условия в стойке. Производитель и системный интегратор может оценить весь тракт и совместимость замены, тогда как один скриншот SMART описывает только часть системы.

Снятый диск не стоит назначать «второй резервной копией» после того, как он дал uncorrectable или провалил самотест. Уничтожьте на нем данные по политике организации, оформите гарантийный возврат или оставьте только для некритичной лабораторной диагностики. Рабочая граница проста: явный отказ или активная потеря читаемости требует замены сейчас; исторический стабильный счетчик требует наблюдения; ошибка интерфейса требует ремонта интерфейса. Все три случая требуют уже существующей и проверенной резервной копии.