Диагностика старого накопителя: почему S.M.A.R.T. может вводить в заблуждение
Некоторое время назад мне подарили старый мини-ПК Intel NUC. Не имея четких планов на устройство, я в итоге решил превратить его в медиацентр для своего старого смарт-телевизора. Установленный внутри 1-терабайтный механический жесткий диск обеспечивал достаточно места для локальной библиотеки контента, что избавляло от необходимости использовать внешние накопители. Однако возникла проблема: диску исполнилось 13 лет, и время от времени он издает тревожные звуки, заставляющие меня с опаской поглядывать на него во время просмотра ТВ.
Первичная проверка и сомнения
Базовые диагностические инструменты, включая утилиту «Диски» в Linux Mint, сообщали, что состояние накопителя в норме. Быстрая проверка командой sudo smartctl -H /dev/sda выдала обнадеживающий, но подозрительный результат: SMART overall-health self-assessment test result: PASSED. Оба источника указывали на отсутствие критических неисправностей у диска HGST (Hitachi).
Изучение отдельных атрибутов S.M.A.R.T. (Self-Monitoring, Analysis, and Reporting Technology) также не выявило немедленной катастрофы. Я отфильтровал вывод команды sudo smartctl -A /dev/sda, чтобы сосредоточиться на ключевых параметрах: Reallocated_Sector, Power_On_Hours, Load_Cycle, Current_Pending и Offline_Uncorrectable.
Использование Scrutiny для глубокого анализа
Чтобы понять, действительно ли диск здоров или находится на грани отказа, я установил бесплатное приложение с открытым исходным кодом Scrutiny (версия 0.9.3). Я развернул его на NUC через Docker Compose, предоставив доступ к физическому диску:
services: scrutiny:
image: ghcr.io/analogj/scrutiny:v0.9.3-omnibus
cap_add: — SYS_RAWIO
devices: — /dev/sda:/dev/sda
volumes: — /run/udev:/run/udev:ro
Запустив контейнер командой docker compose up -d, я получил доступ к инструментам, которые предлагают историю изменений, недоступную для стандартного S.M.A.R.T. Вместо разовой проверки Scrutiny сохраняет данные и отслеживает динамику состояния накопителя.
Интерпретация полученных данных
Scrutiny помогла прояснить показатели, которые изначально выглядели странно. Например, нормализованное значение Load Cycle Count составляло 60, но развернутая строка показала реальный счетчик в 403 715 циклов. Хотя цифра выглядит пугающе, HGST заявляет для этого типа дисков лимит не менее 600 000 циклов парковки головок. Таким образом, диск уже выработал около двух третей своего ресурса.
Аналогичная ситуация произошла с часами наработки: значение 75 оказалось лишь нормализованным показателем, тогда как реальная наработка превысила 11 136 часов. Согласно документации HGST, расчетный срок службы диска составляет около пяти лет или 20 000 часов при штатных нагрузках и рабочих температурах 0–60°C. Важно понимать: эти цифры — не таймер обратного отсчета, а лишь статистические предположения.
Scrutiny помогла мне ответить на главные вопросы:
- Росла ли температура при длительной нагрузке? Да.
- Слишком ли быстро росли циклы парковки? Нет.
- Были ли найдены переназначенные или ожидающие записи сектора? Нет.
- Ухудшались ли атрибуты между проверками? Нет.
Выводы по состоянию диска
Показатели вероятности отказа в Scrutiny не являются прогнозом конкретного процента поломки, но они дают контекст того, что накопитель уже пережил. Мой совет: всегда создавайте базовый снимок S.M.A.R.T. перед стресс-тестированием старого диска. Если в результатах присутствуют ненулевые значения переназначенных (Reallocated), ожидающих (Pending) или неисправимых (Uncorrectable) секторов, считайте, что диск неисправен. В таком случае прекратите тестирование и немедленно приступайте к резервному копированию данных.
Справка: Scrutiny — это дашборд для мониторинга здоровья HDD/SSD с открытым исходным кодом (разработчик Джейсон Кулатунга, поддержка Арам Ахаван). Поддерживает Linux, macOS, FreeBSD, Docker и Windows. Преобразует данные S.M.A.R.T. в наглядные графики температуры, исторические тренды и предупреждения об отказах.
Мониторинг и стресс-тестирование накопителей
Инструмент Scrutiny позволяет отслеживать состояние нескольких дисков через веб-интерфейс и может быть развернут как вручную, так и в контейнере Docker. Программа распространяется по бесплатной лицензии с открытым исходным кодом MIT. В моем случае она помогла оценить реальный ресурс старого накопителя: хотя диск успешно проходил все автоматические тесты, я перестал доверять вердикту «PASSED» и решил подвергнуть его серьезной проверке.
Этапы аппаратной диагностики
Сначала я использовал встроенные в SMART средства самотестирования при помощи команд:
sudo smartctl -t short /dev/sda
sudo smartctl -l selftest /dev/sda
Короткий тест завершился без ошибок за две минуты при наработке в 11 139 часов. Для более глубокой проверки я запустил расширенный тест:
sudo smartctl -t long /dev/sda
sudo smartctl -l selftest /dev/sda
Этот процесс занял около трех часов, в течение которых жесткий диск издавал довольно тревожные звуки. Несмотря на это, расширенный тест был завершен без ошибок при отметке 11 143 часа. Этот результат был важен, так как накопитель физически просканировал свою поверхность, а не просто подтвердил отсутствие критических порогов отказа.
Анализ показателей и имитация нагрузки
После завершения тестов ключевые счетчики SMART оставались в идеальном состоянии: количество переназначенных (reallocated), ожидающих (pending) и неисправимых (uncorrectable) секторов было равно нулю. Число циклов парковки головок составило 403 715, а температура вернулась к рабочим 39–40°C.
Затем я имитировал реальную рабочую нагрузку, выполнив последовательную запись большого объема данных:
dd if=/dev/zero of=~/hdd-media-test/media-test.bin bs=64M count=800 oflag=direct status=progress
Scrutiny зафиксировала рост температуры до 46°C, но показатели SMART по-прежнему оставались «зелеными». Проблема заключалась в том, что сам накопитель издавал ужасающие механические звуки, из-за чего я был вынужден остановить тест на чтение. Иронично, но самым тревожным результатом стал тот, который не смог показать ни один диагностический инструмент: отсутствие ошибок в логах SMART, отсутствие сбоев ввода-вывода или перезагрузок SATA в ядре системы на фоне пугающего механического шума.
Решение о выводе накопителя из эксплуатации
Хотя диск прошел все тесты, я решил заменить его. Быть достаточно исправным для загрузки ТВ-приставки — это не то же самое, что быть надежным хранилищем данных. Объективных аргументов против замены нет: нет ошибок интерфейса или проблемных секторов, а расширенные тесты завершены успешно. Однако, если для текущих задач (загрузка Linux и работа ТВ-интерфейса) более 10 тысяч часов наработки — приемлемый показатель, то создание медиатеки требует высокого уровня надежности.
Копирование сотен гигабайт данных и их последующее ежедневное хранение делают этот диск сомнительным кандидатом. Более 400 000 циклов парковки, возраст и ужасные звуки при нагрузке значат больше, чем «зеленый» статус в SMART. Система SMART способна выявлять типичные признаки выхода из строя, но не может предсказать механические, электронные или внезапные поломки. Я не хочу смотреть фильмы, слушая, как жесткий диск работает на пределе возможностей.
На текущий момент я оставляю Scrutiny установленной и продолжаю использовать диск для легких задач в ТВ-приставке, но планирую создать его образ через FOG-сервер и подобрать новый SSD. Scrutiny не подтвердила математически мою интуицию о скором выходе устройства из строя, но предоставила контекст, доказывающий, что статус «без ошибок» — не единственный стандарт для оценки работоспособности жесткого диска.
Важные нюансы интерпретации данных S.M.A.R.T.
Важно понимать, какие именно показатели в логах S.M.A.R.T. сигнализируют об опасности, а какие требуют лишь периодического наблюдения. Хотя мой диск прошел первичную диагностику, существуют критерии, которые я считаю «тревожными звоночками». Если значения Reallocated_Sector, Current_Pending или Offline_Uncorrectable начинают расти, это прямой индикатор того, что накопитель физически деградирует. В таких случаях любые дальнейшие стресс-тесты могут лишь ускорить окончательную гибель диска, поэтому первым делом нужно приступать к резервному копированию всей ценной информации.
Scrutiny в данном контексте стала для меня незаменимым помощником именно благодаря визуализации исторических данных. В отличие от разовых проверок командой smartctl, этот дашборд строит графики, позволяющие увидеть, как ведут себя показатели во времени. Это помогает найти ответы на критические вопросы, которые обычный вывод командной строки скрывает:
- Росла ли температура при длительной работе диска под нагрузкой? (В моем случае — да).
- Были ли какие-либо атрибуты, показатели которых постепенно ухудшались от одной проверки к другой? (Тут ответ был отрицательным).
Интересно, что Scrutiny также помогла мне расшифровать логику нормализованных значений. Например, расширение строки с показателем Power-On hours продемонстрировало, что реальная наработка диска составляет более 11 136 часов, хотя в упрощенном виде приложение сначала показывало лишь цифру 75. Такой подход — использование «сырых» данных (raw values) вместо интерпретированных — критически важен для глубокого понимания «истории болезни» накопителя.
Ограничения аппаратной диагностики
Несмотря на тщательность, с которой я подошел к тестам, важно признать: ни один программный инструмент не дает 100% гарантии. Мой накопитель успешно прошел как короткий двухминутный тест, так и глубокое трехчасовое сканирование медиа-области диска. После завершения всех этих процедур, проведенных на отметке 11 143 часа наработки, важные счетчики оставались «чистыми»: количество циклов парковки зафиксировалось на значении 403 715, а температурный режим стабилизировался в пределах 39–40°C.
Однако, когда я перешел к имитации реальной рабочей нагрузки — последовательной записи большого объема данных с помощью команды dd (используя oflag=direct для обхода кэша), диск начал издавать настолько отчетливые и пугающие механические шумы, что я был вынужден прервать операцию. Самое неприятное в этой ситуации — полное отсутствие фиксации ошибок на уровне ядра (в логах не было сообщений об I/O ошибках или SATA-ресетах) и пустые журналы ошибок в самом S.M.A.R.T. Это подтверждает, что даже при полной функциональной исправности, подтвержденной софтом, механический износ накопителя может достичь критической точки, которую электроника контроллера просто «не видит» до самого момента отказа.
