Как я S.M.A.R.T. на Alpine Linux настроил и перестал бояться за диски
Я перепробовал кучу способов мониторить диски. Nagios, Zabbix, даже какой-то скрипт на Python самописный. Но всё оказалось либо слишком тяжеловесным, либо требовало отдельного сервера. А Alpine Linux со smartmontools — это буквально пять минут, и ты спишь спокойно.
Всё началось с того, что у меня на сервере сдох диск. Просто взял и умер. Без предупреждения, без синих экранов, без ошибок в логах. Просто пропал из системы. Клиент звонит, орёт, а я сижу и смотрю на пустую директорию. Бэкап был недельной давности. С тех пор я параноик.
S.M.A.R.T. — это штука, встроенная в каждый современный винчестер. Меряет температуру, считает ошибки. Производители закладывают эти датчики, но мало кто их использует. А зря. Это как купить машину с кучей датчиков и выкрутить все лампочки.
Alpine Linux я полюбил за то, что он жрёт 50 мегабайт оперативки. У меня валялся старый Atom-неттоп — Ubuntu на нём еле дышала. Alpine встал как родной, работает полгода без перезагрузки. Идеальный сторож для дисков.
Скачал ISO, записал на флешку:
dd if=alpine-standard-3.21.iso of=/dev/sdb bs=4M status=progress && sync
Только проверь, что /dev/sdb — это флешка, а не системный диск. Я однажды залил образ поверх работающей системы. Хорошо, тестовая была. Теперь всегда lsblk делаю перед записью.
Загрузился, ввёл setup-alpine, выбрал минимальную установку. Всё. Ставлю smartmontools:
apk add smartmontools sysfsutils
Проверяю, видит ли система диски:
smartctl --scan
Если пусто — либо диск древний, либо модуль ядра не подгрузился. У меня было — пришлось modprobe ahci добавить в автозагрузку. Час убил на эту мелочь.
Запускаю короткий тест:
smartctl -t short /dev/sda
Через пару минут смотрю результат:
smartctl -l selftest /dev/sda
Если Completed without error — выдохнул. Если нет — проблемы.
Длинный тест гоняю раз в месяц. На 4-терабайтном WD Red он шёл почти пять часов. Я думал, Alpine завис, проверял нагрузку, перезагружал — а это просто тест такой. Длинный тест ловит битые сектора, которые короткий пропускает. Если данные важны — терпи.
Автоматизировал через cron:
0 3 * * * root smartctl -t short /dev/sda && smartctl -l selftest /dev/sda >> /var/log/smart.log
Каждую ночь в три часа система проверяет диск. Утром открываю лог — и вижу. Если FAILED — бегом бекап.
Главный показатель — Reallocated Sectors Count. Если растёт — диск умирает. У меня был WD Red: за месяц с 0 до 200, через неделю лёг. Данные слил, нервы потрепал. Pending Sectors — то же самое, только диск ещё держится. Температура выше 50 градусов — ставь вентилятор. Я поставил — и Reallocated Sectors замер.
Пробовал smartd для писем, но он спамил. Остановился на cron + лог. Проще.
Alpine крутится месяцами, жрёт копейки. Я проверяю логи каждое утро. Звучит как паранойя? Когда у тебя уже сдох диск без предупреждения — хочется подстелить соломку. Не жди, поставь. Десять минут работы.
История с умершим диском оставила след, и я хочу рассказать её полностью, со всеми подробностями и выводами, которые заставили меня всерьёз заняться мониторингом. Надеюсь, она сэкономит кому-то нервы и данные.
Начну с того, что диск тогда сдох не вдруг. Оглядываясь назад, я понимаю: симптомы были, просто я их не замечал. Диск начал подтормаживать за пару недель до смерти — файлы открывались чуть медленнее, запись иногда подвисала. Я списывал это на нагрузку сервера и занятость процессора. На самом деле это были первые звоночки умирающего диска. Если бы тогда стоял smartd с настроенным мониторингом, я бы увидел растущие счётчики реаллоцированных секторов и успел вынести данные заранее. Вместо этого я получил пустую директорию и недельный бэкап.
Теперь про сам S.M.A.R.T. подробнее. Это самодиагностика, встроенная в каждый современный накопитель — и в механические жёсткие диски, и в SSD, и в NVMe. Каждый диск ведёт журнал своих параметров: температура, количество включений, количество перезапусков, количество ошибок чтения и записи, число переназначенных секторов. Всё это доступно через специальные команды, и утилита smartmontools умеет их читать и интерпретировать. Это как бортовая диагностика автомобиля, которую можно снимать через OBD-разъём. Производители закладывают эти данные, но мало кто их использует, потому что не знает о такой возможности.
Почему я выбрал именно Alpine Linux для этой задачи. Мне нужна была минимальная система-сторож, которая будет работать 24/7 и не требовать к себе внимания. Alpine — это самый лёгкий из популярных дистрибутивов: он использует musl вместо glibc, BusyBox вместо стандартных утилит и занимает совсем немного места на диске и в оперативке. На моём старом Atom-неттопе с двумя гигабайтами памяти Ubuntu еле дышала, а Alpine чувствовал себя отлично. Плюс у него очень быстрая установка и конфигурация — буквально за полчаса поднимается полностью настроенная система.
Про запись образа на флешку я уже упоминал вскользь, но это важный момент, на котором многие обжигаются. Команда dd — мощная и опасная. Одна ошибка в имени устройства — и ты перезаписал не флешку, а системный диск. Я перед каждой записью делаю lsblk и сверяю, что /dev/sdb действительно флешка нужного размера, а не какой-нибудь раздел с данными. Лучше потратить две минуты на проверку, чем потерять систему. С тех пор у меня это правило на автомате.
После установки Alpine и подключения smartmontools первым делом смотришь, видит ли система диски вообще. Команда smartctl —scan выводит список дисков с их типами и шинами. Если список пустой — возможных причин несколько. Первая: диск слишком древний и не поддерживает S.M.A.R.T. вообще. Вторая: для работы нужен модуль ядра, который не загрузился. У меня как раз был случай, когда модуль ahci не подгрузился в автозагрузку, и smartctl ничего не находил. Решилось добавлением modprobe ahci в загрузку и перезагрузкой. Часа такой отладки было достаточно, чтобы запомнить этот грабли навсегда.
Теперь про сами тесты и как их интерпретировать. Короткий тест (smartctl -t short) — это быстрая проверка основных компонентов, занимает пару минут. Он проверяет поверхности чтения-записи, электронику и механику диска без глубокого сканирования. Хорошо для регулярного ежедневного мониторинга. Длинный тест (smartctl -t long) — это уже серьёзная процедура, которая проверяет всю поверхность диска. На больших дисках он может идти часами. Мой 4-терабайтный WD Red тестировался почти пять часов. Сначала я думал, что система зависла, и чуть не перезагрузил её посреди теста. Хорошо, что проверил нагрузку и понял, что диск просто сканируется.
Результаты тестов смотрятся через smartctl -l selftest. Статус Completed without error означает, что диск прошёл проверку без обнаруженных проблем. Если статус другой — например, Completed read failure — в выводе будут указаны конкретные сектора, которые не читаются. Это повод задуматься о резервном копировании и, возможно, о замене диска.
Но главные данные не в тестах, а в постоянных атрибутах S.M.A.R.T. Это таблица показателей, которые обновляются постоянно. Самый важный для меня — Reallocated Sectors Count. Этот счётчик показывает, сколько секторов диск признал неисправными и переназначил из резерва. Рост этого числа — верный признак деградации диска. У меня был случай, когда за месяц счётчик вырос с нуля до двухсот, а через неделю диск лёг окончательно. Если бы я мониторил этот параметр, я бы заметил рост на ранней стадии.
Не менее важен Pending Sectors Count — количество секторов, которые диск подозревает в нестабильности, но ещё не переназначил. Если это число не нулевое — значит, диск начал терять сектора, и процесс, скорее всего, будет продолжаться. Плюс следи за температурой: у механических дисков рабочая температура до 50 градусов, выше — это уже стресс. У меня один диск стабильно держал 55 градусов, и Reallocated Sectors рос. Я поставил вентилятор на корпус — температура упала до 45, и счётчик остановился. Температура напрямую влияет на долговечность.
Что ещё стоит знать про атрибуты. Load Cycle Count показывает, сколько раз диск «парковал» головки — для дисков в ноутбуках и NAS это важно, чрезмерная парковка изнашивает механику. Power On Hours показывает реальное время работы диска — полезно при покупке б/у. Raw Read Error Rate и Seek Error Rate — количество ошибок чтения и позиционирования. Единичные ошибки — это нормально, но стабильный рост — тревожный сигнал. Советую изучить хотя бы десяток основных атрибутов, чтобы понимать, что говорит диск.
Про автоматизацию. Я упоминал cron в три часа ночи. Расскажу, как устроен мой текущий вариант, потому что он эволюционировал. Сначала я просто запускал короткий тест раз в день и складывал результат в лог. Потом добавил сбор атрибутов: раз в день снимаю таблицу S.M.A.R.T. и тоже пишу в лог. Так я могу видеть динамику: рос ли Reallocated Sectors за неделю, менялась ли температура. Плюс в тот же крон-скрипт я добавил проверку — если число переназначенных секторов выросло за сутки, скрипт шлёт уведомление. На голом Alpine для простоты это делается записью в файл, но можно настроить и почту через msmtp.
Про smartd я честно скажу: да, это демон, который сам мониторит диски и может слать письма при проблемах. Но он спамил уведомлениями по любому поводу, и я его отключил. Мой вариант — cron плюс лог — проще и предсказуемее: я сам решаю, что мне важно, и сам читаю результаты утром. Если у тебя диски в RAID с горячей заменой — smartd может быть полезен, там автоматика важнее. Но для обычного сервера достаточно регулярного cron.
Ещё пара деталей про сам файл лога. Я сделал так, чтобы каждая запись была с датой — это критично для отслеживания динамики. Без дат ты не поймёшь, когда начались проблемы. И я веду лог по одному файлу на все диски, добавляя имя устройства в строку. Так весь мониторинг смотрится в одном месте за минуту. Утром я открываю лог, смотрю, нет ли FAILED и не выросли ли счётчики, и спокойно занимаюсь делами.
Что касается новых дисков и SSD, тут есть нюанс. У SSD свои атрибуты: Wear Leveling Count (износ ячеек), Percentage Used (процент износа), количество записанных терабайт (Total LBAs Written). Для NVMe используется формат NVMe S.M.A.R.T., и smartctl умеет его читать. Так что метод применим к любому современному накопителю — нужно только знать, какие атрибуты смотреть для конкретного типа. Это тема отдельной статьи, но знать о различии стоит заранее.
Отдельно скажу про бэкапы, потому что мониторинг без бэкапов — это половина дела. S.M.A.R.T. помогает заметить проблему вовремя и успеть вынести данные. Но если диск умирает мгновенно — например, электроника или механика выходят из строя разом, — никакой мониторинг не спасёт. Поэтому моя паранойя теперь выглядит так: S.M.A.R.T. каждый день, полный бэкап раз в неделю, инкрементальный — каждый день. Один сдохший диск научил меня этому навсегда.
Подведу итог тем, что я делаю конкретно, чтобы ты мог повторить. Ставлю Alpine на старый неттоп или использую существующий сервер. Устанавливаю smartmontools. Смотрю smartctl —scan, убеждаюсь, что диски видны. Настраиваю крон: ночью короткий тест, сбор атрибутов в лог. Утром читаю лог. Раз в месяц — длинный тест. При любом росте счётчиков или FAILED — делаю бэкап и планирую замену диска. Всё. Десять минут разовой настройки, и дальше — просто привычка проверять лог по утрам.
Звучит как паранойя? Когда у тебя уже сдох диск без предупреждения и унёс данные, ты перестаёшь считать это паранойей. Ты считаешь это нормальной гигиеной. S.M.A.R.T. не предсказывает поломку со стопроцентной точностью, но он даёт тебе шанс заметить проблему до того, как станет поздно. Этим шансом я и пользуюсь каждый день.