Мониторинг и обслуживание системы хранения файлов: SMART, логи и профилактика в 2026 году

Зачем мониторить систему хранения в 2026 году

Годовой процент отказов (AFR) у накопителей, работающих в серверных стойках круглосуточно, держится около 1.5%, а у отдельных моделей превышает 5%. Парк из 200 дисков даёт несколько отказов за год, и часть из них приходится на ночную смену или выходные. RAID и ZFS переживают потерю одного накопителя, но деградация массива, тихие ошибки чтения и поспешная замена диска способны унести весь пул.

Регулярный мониторинг превращает аварию в плановую работу. Диск с растущим числом переназначенных секторов меняется в удобное окно, а не в момент, когда массив ушёл в FAULTED. На практике решение опирается на четыре сигнала: атрибуты SMART, состояние массива, логи ядра и контроллера, свободное место вместе с inode.

Набор команд для дежурного администратора:

smartctl -a /dev/sdX: полный отчёт по накопителю;
zpool status -v для ZFS, mdadm --detail /dev/md0 для Linux RAID;
dmesg -T | grep -i error: ошибки ядра за последние часы;
df -h и df -i: свободное место и inode.

Сводку метрик и инструментов для наблюдения за СХД мы собрали отдельно: мониторинг систем хранения данных, ключевые метрики и инструменты для администратора. Дальше разберём каждый сигнал с командами и порогами.

Ключевые SMART-атрибуты для диагностики деградации диска

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

ID	Атрибут	Что показывает	Порог тревоги
5	Reallocated_Sector_Ct	секторы, переназначенные из резервной области	рост на 5 и более за месяц, значение выше 10
187	Reported_Uncorrect	ошибки, которые диск не смог исправить	любое значение выше 0
188	Command_Timeout	команды, не уложившиеся в таймаут	систематический рост
194	Temperature_Celsius	температура корпуса	выше 50 для HDD, выше 70 для SSD
197	Current_Pending_Sector	секторы, ожидающие перераспределения	любое значение выше 0
198	Offline_Uncorrectable	секторы, недоступные при офлайн-сканировании	любое значение выше 0

Две команды закрывают большинство задач. smartctl -a /dev/sdX выводит полный отчёт по накопителю, smartctl -H /dev/sdX показывает строку самодиагностики (SMART overall-health self-assessment test result). Результат PASSED означает лишь то, что не пройден порог FAILING. Диск с двумя десятками переназначенных секторов спокойно показывает PASSED и умирает в течение суток.

Пример вывода 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       -       24
  9 Power_On_Hours          0x0032   081   081   000    Old_age   Always       -       14208
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
188 Command_Timeout         0x0032   100   100   000    Old_age   Always       -       2
194 Temperature_Celsius     0x0022   034   050   000    Old_age   Always       -       34
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       8
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       8
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

Читаем результат: 24 переназначенных сектора, 8 секторов ждут перераспределения, 8 недоступны при офлайн-сканировании, температура 34 градуса. Колонки VALUE и WORST равны 100, то есть производитель считает запас нормальным. Реальную картину даёт только RAW_VALUE.

Как читать raw-значения SMART у разных производителей

У Seagate поле RAW_VALUE атрибута 5 часто содержит служебные байты в старшей части, а число переназначений занимает младшие 32 бита. Western Digital для атрибута 194 отдаёт текущую температуру в старшем байте, а младшие байты отводит под минимум и максимум за всю историю. Сравнивать такие числа между брендами напрямую нельзя: скрипт, который берёт колонку RAW_VALUE целиком, будет врать.

Для автоматизации надёжнее JSON: smartctl -A -j /dev/sdX возвращает структурированный вывод, где каждое значение лежит в отдельном поле. Парсер не зависит от ширины колонок и форматирования, а часть полей доступна только в JSON-режиме.

NVMe-накопители классических атрибутов не имеют. Их состояние описывают поля Critical Warning, Available Spare, Available Spare Threshold, Percentage Used и Media and Data Integrity Errors. Отчёт выводит smartctl -a /dev/nvme0 или nvme smart-log /dev/nvme0. Журнал ошибок конкретного устройства показывает smartctl -l error /dev/nvme0n1. Рост Media and Data Integrity Errors означает, что контроллер SSD терял данные при чтении, и такой диск меняют без обсуждений.

Пороги и тренды: когда бить тревогу

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

Рабочие пороги:

Current_Pending_Sector и Offline_Uncorrectable больше нуля: сектор физически не читается, готовьте замену;
Reported_Uncorrect больше нуля: диск уже отдавал ошибки приложению;
Reallocated_Sector_Ct выше 10 или рост на 5 и более за месяц: планируйте замену в ближайшее окно обслуживания;
Command_Timeout в систематическом росте: сначала проверьте кабель, питание и контроллер, потом выносите вердикт по диску;
Temperature_Celsius выше 50 у HDD и выше 70 у SSD: разбирайтесь с охлаждением, а не с накопителем.

Автоматизируйте сверку через smartd или внешний коллектор. Пошаговая настройка тестов и писем в TrueNAS разобрана в руководстве настройка и интерпретация SMART-мониторинга в TrueNAS.

Часть отказов SMART не предсказывает. Контроллер, питание и прошивка выходят из строя без единого изменения атрибутов, поэтому к SMART добавляют логи и проверку массива.

Проверка состояния RAID-массива и ZFS-пула

Состояние ZFS-пула показывает команда zpool status -v. Строка state принимает значения ONLINE, DEGRADED, FAULTED, UNAVAIL и REMOVED. Три счётчика READ, WRITE и CKSUM считают ошибки чтения, записи и контрольных сумм за время работы пула.

  pool: tank
 state: DEGRADED
status: One or more devices has experienced an unrecoverable error.
        Applications are unaffected.
action: Determine if the device needs to be replaced.
  scan: scrub repaired 0B in 05:12:33 with 0 errors on Sun Sep  6 03:12:45 2026
config:

        NAME        STATE     READ WRITE CKSUM
        tank        DEGRADED     0     0     0
          raidz1-0  DEGRADED     0     0     0
            sda     ONLINE       0     0     0
            sdb     FAULTED      3    12     8  too many errors
            sdc     ONLINE       0     0     0

Диск sdb получил 3 ошибки чтения, 12 ошибок записи и 8 ошибок контрольных сумм, после чего пул пометил его как FAULTED. Данные читаются с оставшихся дисков raidz1. Ненулевой CKSUM в строке диска означает повреждение на носителе или на пути к нему, счётчик CKSUM на уровне пула показывает, сколько ошибок дошло до приложения.

Полный обзор команд ZFS, снапшотов и замены дисков собран в шпаргалке ZFS для системы хранения: команды и практические приёмы администрирования.

Как запустить и интерпретировать scrub в ZFS

Команда zpool scrub tank запускает проверку всех блоков по контрольным суммам. Прогресс смотрят через zpool status: строка scan показывает процент и расчётное время. На пуле в 50 ТБ с медленными дисками проверка идёт сутки и дольше, поэтому запускать её лучше в непиковые часы.

Найденные ошибки ZFS пытается исправить из копий: на raidz хватает чётности, при copies=2 хватает второй копии блока. Если после scrub счётчики CKSUM у диска снова растут, неисправен носитель или путь к нему. Порядок действий: проверить кабель и полку, затем заменить диск командой zpool replace tank sdb /dev/sdd. Восстановление (resilvering) идёт в фоне, следить за ним удобно тем же zpool status. Регулярность scrub: раз в месяц для обычных данных, раз в одну-две недели для критичных.

Подход к контролю целостности на уровне блоков, аудит доступа и резервное копирование по схеме 3-2-1 разобраны в материале система качества хранения данных.

Диагностика RAID через mdadm и логи ядра

Для Linux RAID состояние массива показывают mdadm --detail /dev/md0 и краткий файл /proc/mdstat. В выводе mdadm смотрите строку State и список устройств с флагами. Диск с флагом faulty или F выпал, остальные работают. Серийный номер отказавшего накопителя уточняют командой smartctl -i /dev/sdb: менять нужно по серийнику, потому что имя устройства после перезагрузки может измениться.

Логи ядра по RAID фильтруются командами dmesg | grep -i raid и journalctl -k | grep -i md. Сообщение вида md/raid1:md0: Disk failure on sdb, disabling device прямо указывает виновника. Замена выглядит так: mdadm --manage /dev/md0 --remove /dev/sdb, физическая замена, затем mdadm --manage /dev/md0 --add /dev/sdd.

Аппаратные RAID-контроллеры состояние через mdadm не показывают. Для LSI и Broadcom используйте storcli /c0/eall/sall show или megacli с ключом -LDInfo, отдельно проверяйте батарею кэша (BBU). Разряженная батарея переводит кэш в режим write-through и роняет производительность.

При degraded массиве замена диска без свежей резервной копии опасна: перестройка читает все оставшиеся накопители, и второй сбойный диск уносит данные.

Анализ логов контроллеров и файловых систем

Логи ядра лежат в dmesg, journalctl -k, /var/log/syslog и /var/log/messages. Быстрый фильтр по ключевым словам: dmesg -T | grep -i error. Искать стоит строки I/O error, ATA error, SCSI error, medium error, failed command, UDMA CRC error. Для ZFS добавьте zpool events и zpool status -v, для Btrfs команду btrfs device stats /mnt.

Настройка smartd для автоматических оповещений

Демон smartd из пакета smartmontools рассылает письма при изменении атрибутов и провале тестов. Базовая строка в /etc/smartd.conf:

/dev/sda -a -o on -S on -s (S/../.././02|L/../../7/03) -m admin@example.com

Опции расшифровываются так: -a включает наблюдение за всеми атрибутами, -o on запускает автоматический офлайн-тест при простое, -S on сохраняет атрибуты между циклами питания, -s задаёт расписание (короткий тест ежедневно в 02:00, длинный по воскресеньям в 03:00), -m указывает адрес для писем. После правки конфигурации демон перезапускают, синтаксис проверяют запуском smartd -q one-shot. NVMe-накопители smartd покрывает не полностью, для них нужен nvme-cli и отдельный сбор метрик.

Что искать в логах при ошибках чтения

Типичные сообщения при проблемах с SATA-диском:

ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0;
blk_update_request: I/O error, dev sda, sector 12345;
critical medium error, dev sda, sector 987654;
ata1.00: status: { DRDY ERR }.

Ошибка critical medium error указывает на сбойный сектор, рост UDMA_CRC_Error_Count в SMART связан с кабелем, а серия exceptions на конкретном порту часто говорит о питании или контроллере. Порядок проверки: снять SMART, переподключить или заменить SATA-кабель, проверить разъём питания, при повторе ошибок на том же диске заменить накопитель.

Разовая ошибка после скачка питания или сброса контроллера не приговор. Ошибки, повторяющиеся на одном устройстве часами и днями, говорят о деградации. Считайте частоту: три I/O error за сутки на одном диске требуют разбора, одна за полгода на разных дисках остаётся статистическим шумом.

Мониторинг свободного места и inode: больше чем df

Ошибка "No space left on device" не всегда означает, что закончились блоки данных. Linux требует свободный inode для каждого нового файла, путь может лежать на другом монтировании, а ядро возвращает ту же ошибку при исчерпании лимита inotify-наблюдений. Диагностику начинают с точного пути, который дал сбой, а не с корня.

Порядок действий:

Проверить конкретный путь: df -h /var/lib/app/cache. Колонка Mounted on покажет, какая файловая система реально держит каталог.
Уточнить источник, тип и точку монтирования: findmnt --target /var/lib/app/cache. Сервер может держать /var, хранилище контейнеров и данные приложений на разных файловых системах, и каждая заполняется независимо.
Посмотреть inode: df -i /var/lib/app/cache. Строка с IUse% 100% при свободных блоках объясняет сбой: файловая система с миллионами мелких кэш-, сессионных и временных файлов исчерпала inode.
Найти каталоги с наибольшим числом файлов: du --inodes -x -d 2 /path | sort -n | tail -20. Ключ -x запрещает переход на другие файловые системы.
Посмотреть файлы, которые уже удалены, но остаются открытыми: lsof +L1. Место не освободится, пока процесс не закроет дескриптор.
Проверить лимит наблюдений: cat /proc/sys/fs/inotify/max_user_watches. Исчерпание лимита даёт ту же ошибку "No space left on device".

Для поиска больших каталогов подходит du -sh * | sort -h, для проверки кэша пакетов du -sh /var/cache/apt/archives. Типичные источники миллионов мелких файлов: кэши приложений без истечения старых записей, слои образов контейнеров и кэш сборки, данные мониторинга, ротированные логи, временные файлы неудачных заданий.

Как найти и очистить временные файлы безопасно

Сначала смотрите список, потом удаляете. Команда find /tmp -xdev -type f -mtime +7 -print покажет файлы старше недели и ничего не тронет. Если в списке только ненужное, тот же вызов с -delete выполнит удаление. Ключ -xdev не даёт команде выйти за пределы файловой системы /tmp.

Не запускайте широкие rm по каталогам приложений, пока неизвестны правила хранения. Кэш APT очищает apt clean, логи ротирует logrotate, а собственные кэши чистит само приложение. Удаление открытого файла место не освобождает: inode и блоки живут, пока процесс держит дескриптор.

Особенности Btrfs: почему df врёт

Btrfs выделяет место под данные и метаданные отдельными чанками. Возможна ситуация, когда место данных или метаданных исчерпано, а df показывает свободную ёмкость. Реальное распределение показывает btrfs filesystem usage /affected/path. При заполненных метаданных помогает балансировка: btrfs balance start -m /path. Операция идёт долго и нагружает диски, поэтому её запускают в окно обслуживания и следят за ходом через btrfs balance status. Ошибки устройств удобно считать командой btrfs device stats.

Контроль температуры и профилактические проверки

Температуру выводит smartctl -A /dev/sda | grep Temperature и smartctl -a /dev/nvme0 для NVMe (поле Temperature Sensor 1). Норма для HDD лежит в диапазоне 30-45 градусов, для SSD 30-50. Нагрев выше 50 у жёсткого диска и выше 70 у SSD ускоряет износ и повышает вероятность ошибок чтения.

Проверяйте охлаждение: пыль на радиаторах и фильтрах, работу вентиляторов, плотность установки дисков. В NAS-корпусах накопители, поставленные вплотную без обдува, греются на 10-15 градусов сильнее. Для HDD добавляются вибрации: слабое крепление салазок повышает число ошибок позиционирования.

Самотестирование запускается двумя командами: smartctl -t short /dev/sda раз в неделю и smartctl -t long /dev/sda раз в месяц. Результаты смотрите через smartctl -l selftest /dev/sda. Поверхностную проверку секторов выполняет badblocks в режиме чтения (badblocks -n) или в разрушительном режиме записи на новом диске до ввода в строй. В ZFS роль такой проверки играет zpool scrub, в Linux RAID проверка целостности через запись check в /sys/block/md0/md/sync_action и контроль mismatch_cnt.

Ежедневные, еженедельные и ежемесячные проверки

Периодичность	Действия
Ежедневно	df -h и df -i по точкам монтирования, zpool status -v или cat /proc/mdstat, dmesg -T \| grep -i error, разбор ночных алертов
Еженедельно	smartctl -a по всем дискам, проверка температуры, короткий SMART-тест, контроль заданий резервного копирования
Ежемесячно	длинный SMART-тест, zpool scrub, проверка целостности RAID, очистка временных файлов, ревизия прошивок, тестовое восстановление из бэкапа

Ручной обход заменяется расписанием: cron запускает скрипты сбора метрик, отправляет отчёт на почту и создаёт тикет при выходе значения за порог. Регламент и пороги алертов для больших парков описаны в руководстве система мониторинга и проактивного обслуживания дисковых массивов.

Предупреждение перегрева и износа SSD

Износ SSD отслеживается по полю Percentage Used у NVMe и атрибуту Wear_Leveling_Count (ID 177) у SATA. Отметка 80% и выше означает, что пора планировать замену: после исчерпания ресурса накопитель переходит в режим только для чтения или отказывает. Полезно смотреть и Total_LBAs_Written, чтобы оценить фактическую нагрузку записи.

Продлить жизнь накопителям помогает запас свободного места для выравнивания износа, периодический TRIM через fstrim.timer и отказ от полной перезаписи данных без необходимости. Для нагрузочных проверок и экспериментов с версиями ПО берите отдельный стенд, например Timeweb Cloud с гибко настраиваемыми серверами и хранилищем: тестировать новые версии утилит лучше вне продакшена.

Типичные ошибки интерпретации показателей

Большинство ложных выводов повторяется из раза в раз. Ниже список с разбором.

Оценка только текущего значения. Атрибут с 20 переназначенными секторами, стабильный три года, безопаснее атрибута, который вырос с 0 до 6 за неделю.
Сравнение raw-значений разных брендов напрямую. Seagate упаковывает в атрибут 5 служебные байты, Western Digital хранит в атрибуте 194 температуру в старшем байте вместе с историческим минимумом и максимумом.
Вера в нормализованные колонки. VALUE 100 и пустой WHEN_FAILED означают лишь, что производитель не считает запас исчерпанным, а не что диск здоров.
Путаница df и du. df показывает занятое место файловой системы, du суммирует размеры файлов. Расхождение дают удалённые открытые файлы, снапшоты, разреженные файлы и зарезервированные под root блоки ext4 (обычно 5%).
Ожидание, что SMART предскажет любой отказ. Часть дисков и контроллеров выходит из строя внезапно, поэтому мониторинг сочетают с резервным копированием.
Игнорирование логов контроллера и батареи кэша. Деградация BBU и ошибки expander не видны ни в SMART, ни в df.
Неверное чтение ZFS. ARC живёт в оперативной памяти и на df не влияет, а zpool list и zfs list показывают разные числа: первый отдаёт сырой объём с учётом чётности, второй доступный для файлов.
Иллюзия свободного места на Btrfs. df может показывать запас, когда метаданные уже исчерпаны; проверяйте btrfs filesystem usage.
Ложные срабатывания scrub. Ошибки контрольных сумм нередко приходят от кабеля, backplane или expander, а не от диска. Перед заменой носителя проверьте тракт.
Пренебрежение лимитом inotify. Тысячи наблюдений от одного сервиса дают "No space left on device" при свободных блоках и inode.

Актуальность инструкций в 2026 году и адаптация под разные версии

Базовые команды smartctl, mdadm и zpool остаются стабильными годами, обратная совместимость у них высокая. Меняются детали: в smartmontools 7.5 и новее расширен список поддерживаемых накопителей, в ZFS 2.3 обновился вывод диагностических команд и добавились поля в zpool status, mdadm 4.x сохранил синтаксис управления массивами.

Перед применением проверьте версии: smartctl --version, mdadm --version, zpool version или cat /sys/module/zfs/version, uname -r для ядра. В TrueNAS 25.04 (Scale) часть настроек живёт в веб-интерфейсе, и правка конфигурации напрямую через CLI может не сохраниться после обновления. Меняйте то, что видно в интерфейсе, либо фиксируйте изменения в отдельном скрипте.

Возражение "я это уже пробовал, и не сработало" обычно связано с окружением, а не с командой. Частые причины: указан не тот путь или не то устройство (sdb после перезагрузки стал sdc), используется аппаратный RAID вместо HBA, поэтому mdadm массив не видит, кабель или разъём питания неисправны, версия утилиты старая. Порядок проверки: сверьте вывод со своим, уточните синтаксис по man-странице, проверьте версии утилит, воспроизведите сценарий на тестовом стенде.

Заключение: внедряем профилактику в ежедневную работу

Начните с трёх шагов. Первый: настройте smartd и сбор базовых метрик (df -h, df -i, zpool status или mdadm --detail) с отправкой алертов на почту или в мессенджер. Второй: введите регулярные проверки по чек-листу из раздела о периодичности и заведите журнал замен. Третий: автоматизируйте сбор логов и отчётов, чтобы дежурный видел картину за минуту, а не собирал её по кускам.

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