Диск в RAID сыпался месяц, а мониторинг молчал

MAATRIX

Панель хостинга показывает: RAID-массив деградирован, второй диск помечен как failed. Ещё вчера всё было зелёным — по крайней мере, так казалось, потому что никто не смотрел глубже статуса «OK» в интерфейсе. Разберём именно такой случай: почему второй диск не «внезапно сломался», а просто первым добрался до точки, откуда нет возврата — и что нужно было увидеть за месяц до этого.

Момент, когда стало плохо

Обычно это выглядит так: приходит письмо от хостинга или срабатывает алерт в панели — один диск массива выведен из RAID из-за ошибок. Не страшно, для этого и нужна избыточность: RAID 1, 5, 6 и 10 переживают отказ одного диска без потери данных, массив работает в деградированном режиме. Проблема начинается, когда через день-две приходит второе такое же письмо — про другой диск того же массива.

На RAID 5 второй отказ — это конец массива, данные только из бэкапа. На RAID 6 остаётся ещё один диск про запас, но избыточность уже исчерпана, и новая ошибка чтения при rebuild может привести к тому же. На RAID 10 отказ второго диска фатален, только если он из той же зеркальной пары — но в момент паники редко кто помнит, какой диск в какой паре.

Первым делом смотрят состояние массива командой mdadm --detail /dev/md0 — в выводе важны State: clean, degraded, Failed Devices и строка с пометкой faulty напротив упавшего устройства.

Дальше вопрос, который стоит задать сразу, а не через месяц: диск, отказавший первым — он правда сломался внезапно, или у него была история?

Реконструкция: что рассказывает SMART-история первого диска

Если на сервере хоть когда-то работал smartd, история первого диска остаётся в логах — /var/log/syslog, /var/log/messages или в собственном логе smartd. Если ничего не логировалось, остаётся только текущий снимок SMART: smartctl -a /dev/sdc.

Три атрибута обычно и рассказывают всю историю:

• Reallocated_Sector_Ct (ID 5) — сколько секторов диск уже перенёс в резерв из-за ошибок. Растёт — поверхность физически сыпется.
• Current_Pending_Sector (ID 197) — сектора, которые не удалось прочитать, ждут переназначения. Это самый ранний и честный сигнал.
• Offline_Uncorrectable (ID 198) — сектора, не восстановленные даже фоновым самотестом.

Если история логировалась, типичная картина такая: месяц назад Reallocated_Sector_Ct был единицы, Current_Pending_Sector — ноль. Дальше оба значения постепенно растут, по несколько секторов за раз, а не разом. Формальный порог, после которого статус диска меняется на FAILED, срабатывает намного позже реального начала деградации — пороги SMART специально консервативны.

Короче: диск не «сломался вчера», он деградировал недели, просто это никто не смотрел. RAID компенсировал единичные ошибки чтения на лету, панель хостинга показывала «OK» до момента, пока mdadm формально не исключил диск из массива.

Что происходит на уровне RAID в момент отказа диска — отдельно разобрано в статье как работает RAID при отказе диска.

Почему это никто не увидел

Обычно один из трёх сценариев, и все три — не про технику, а про процесс.

Сценарий 1: smartd не запущен вовсе. Пакет smartmontools не установлен, либо демон не в автозапуске. SMART-данные физически на диске, но без демона, который читает их регулярно, этого никто не делает — до самого отказа.

Сценарий 2: smartd работает, но никуда не пишет алерты. Самый обидный вариант: мониторинг как бы есть, а толку ноль. Демон исправно проверяет диски, в syslog тихо копится строчка про pending-секторы — но на этот лог никто не подписан. Формально мониторинг «стоит», по факту это архив для будущего расследования, а не мониторинг.

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

Если на сервере вообще стоит аппаратный RAID — отдельный вопрос, кому он реально нужен, разобран в статье аппаратный RAID-контроллер в выделенном сервере: кому это реально нужно.

smartd, который реально шлёт алерты

Мало того, чтобы демон был запущен — он должен куда-то сообщать. Минимальная рабочая настройка на Debian/Ubuntu:

apt install smartmontools mailutils

В /etc/smartd.conf — не оставляем закомментированным дефолтом, прописываем явно:

DEVICESCAN -a -o on -S on -s (S/../.././02|L/../../6/03) -m root -M exec /usr/share/smartmontools/smartd-runner

Разбор опций: -a — все атрибуты в лог; -o on/-S on — офлайн-тестирование и сохранение атрибутов между перезагрузками; -s (...) — короткий самотест ежедневно в 2:00, длинный — по субботам в 3:00; -m root — куда слать письмо; -M exec — скрипт-обработчик события (можно подставить свой, с отправкой в Telegram или на webhook). Если локальная почта не настроена, проще перенаправить письма через msmtp как релей — иначе алерты осядут в локальном mbox, который никто не читает.

Обязательно проверьте, что уведомления реально работают — команда smartd -q onecheck --debug -M test шлёт тестовое письмо принудительно, независимо от состояния дисков. Не пришло — весь остальной конфиг бессмысленен, получится то же «мониторинг стоит, но молчит». После правки конфига: systemctl restart smartd && systemctl enable smartd.

Как настроить это с нуля вместе с остальными базовыми проверками диска на VPS — по шагам в статье как установить и настроить мониторинг диска на VPS.

Что смотреть в SMART регулярно, а не только когда прижмёт

Реальная практика — следить за трендом, а не за отдельным значением. Reallocated_Sector_Ct = 3 сам по себе ничего не значит, а вот «было 0, через две недели 3, ещё через неделю 11» — сигнал готовить замену диска заранее.

Быстрая проверка smartctl -H /dev/sda даёт ответ PASSED, который не означает «диск идеален» — это означает «пороги ещё не превышены». Диск с растущим, но не критическим Current_Pending_Sector может показывать PASSED неделями. Полезнее смотреть конкретные атрибуты: smartctl -A /dev/sda | grep -E 'Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable'.

Для NVMe атрибуты другие (smartctl -a /dev/nvme0) — важны Media and Data Integrity Errors, Percentage Used и Available Spare из Health Log, но смысл тот же: есть ли уже фактическая деградация носителя.

Если на сервере есть Prometheus/Grafana, атрибуты SMART удобно вытаскивать через smartctl_exporter и строить график тренда, а не полагаться на память «вроде на прошлой неделе было меньше». Общий подход к мониторингу состояния железа, включая температуру и диски, разобран в статье мониторинг здоровья железа.

Scrub и проверка массива целиком

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

Для mdadm: echo check > /sys/block/md0/md/sync_action, прогресс — через cat /proc/mdstat, результат — через cat /sys/block/md0/md/mismatch_cnt.

Ненулевой mismatch_cnt на RAID 1/10 обычно не катастрофа (неатомарная запись при отключении питания даёт единицы расхождений), но растущее значение от проверки к проверке — повод разбираться с дисками, а не списывать на погрешность.

Большинство дистрибутивов включают периодический scrub через cron/systemd timer в пакете mdadm (обычно раз в месяц) — но стоит проверить явно (cat /etc/cron.d/mdadm), а не полагаться, что «наверное, где-то само настроено». Если ничего нет, добавляем сами: 0 3 1 * * root echo check > /sys/block/md0/md/sync_action.

Панель хостинга или веб-интерфейс аппаратного контроллера обычно показывает только бинарный статус массива, без трендов по дискам и результатов scrub — за это отвечает ОС, а не контроллер. Устойчивость к таким постепенным отказам у разных уровней разобрана в статье RAID 10 vs RAID 6: что выбрать.

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