RAID и RAID-контроллеры

Мониторинг RAID: S.M.A.R.T., Patrol Read, Consistency Check и оповещения

Регламент мониторинга RAID: какие статусы отслеживать, как различать фоновые проверки и безопасно реагировать на предупреждения.

16 минут
Средний
Абстрактная иллюстрация мониторинга серверного хранилища
Мониторинг RAID должен непрерывно получать события от массива, каждого накопителя и контроллера, включая его кэш и защиту питания. Ежедневный просмотр сводки нужен для контроля, но не заменяет оповещения: отказ, потеря избыточности, остановка Rebuild или переход кэша в Write-Through требуют реакции до следующей проверки. S.M.A.R.T., Patrol Read, Consistency Check и проверка mdadm решают разные задачи и сами по себе не подтверждают целостность пользовательских файлов.

Сначала составьте карту объектов мониторинга

Для каждого сервера зафиксируйте владельца RAID: аппаратный RAID-контроллер, Linux mdadm или другую подсистему хранения. Не смешивайте уровни: логический диск, который ОС видит как один /dev/sdX, может быть Online, пока один из физических дисков уже выдал предупреждение. И наоборот, недоступность логического диска не доказывает отказ конкретного накопителя.

  • Логический уровень: имя и RAID-уровень массива, состояние logical/virtual drive, число ожидаемых и работающих членов, деградированный режим, Offline, Failed, активный Rebuild и его прогресс.
  • Физические диски: enclosure:slot или иной неизменный адрес, модель, серийный номер, WWN при наличии, интерфейс, состояние, Predictive Failure, счётчики и журналы ошибок, участие в массиве или spare.
  • Контроллер и путь подключения: модель контроллера, версия прошивки, драйвер, состояние портов, корзины и экспандера, события потери связи и одновременное исчезновение нескольких дисков.
  • Кэш записи: текущая политика, состояние RAID-кэша, наличие грязного кэша, переходы между Write-Back и кэшем со сквозной записью.
  • Защита кэша: состояние BBU, CacheVault, flash-модуля или суперконденсатора — именно того механизма, который установлен в данном контроллере.

Не используйте только имя устройства ОС

Имена /dev/sdX могут измениться после перезагрузки, перестановки дисков или смены порядка обнаружения. Для аппаратного RAID сохраняйте соответствие physical drive → enclosure:slot → serial/WWN; для mdadm — serial/WWN, путь /dev/disk/by-id/ и членство в массиве. Это нужно до любого извлечения диска.

Разделите непрерывные, ежедневные и еженедельные проверки

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

ПериодЧто контролироватьРезультат
НепрерывноСостояния массива и физических дисков, Predictive Failure, ошибки контроллера, кэша и защиты кэша, старт и остановка Rebuild, события корзины и путей подключенияСобытие приходит ответственному через почту, webhook или централизованный мониторинг
ЕжедневноСводка всех массивов, незакрытые предупреждения, новые ошибки и изменение счётчиков относительно базовой линии, прогресс активных фоновых задачНет неразобранных событий; известны массивы без избыточности и задачи, которые не завершились
ЕженедельноЖурналы контроллера и ОС, состояние резервных копий и результат проверки восстановления, план и результаты Patrol Read, Consistency Check либо mdadm checkЕсть зафиксированные результаты и нет пересечения тяжёлых задач в одном окне
После изменения или перезагрузкиВидимость контроллера и всех ожидаемых дисков, состояние массива, политика кэша, защита кэша, foreign/preserved cache, автосборка mdadm, доставка событияКонфигурация соответствует зафиксированной карте объектов

Для оценки роста ошибок важна базовая линия: сохраните исходные счётчики и сравнивайте новые значения с предыдущими снимками. Один счётчик не равен диагнозу. Например, ошибки нескольких дисков одновременно могут указывать на общую корзину, кабель, SAS-экспандер, питание или контроллер, а не на одновременный отказ накопителей.

Что проверяют S.M.A.R.T., Patrol Read и Consistency Check

МеханизмЧто делаетЧего не доказывает
S.M.A.R.T. и журналы накопителяПоказывают доступные диагностические признаки и историю ошибок отдельного дискаЧто отказ обязательно случится или не случится; правильность RAID-чётности и пользовательских файлов
Patrol ReadФоново читает доступные области физических дисков в поддерживаемой реализации и может выявить скрытые ошибки чтения до RebuildСогласованность чётности или зеркальных копий; целостность файловой системы и данных приложения
Consistency CheckСравнивает избыточность: чётность с пересчитанным значением либо копии в зеркале, в зависимости от RAID-уровня и реализацииКакая версия пользовательских данных была правильной до расхождения
mdadm checkЗапускает проверку согласованности md-массива средствами ядра LinuxЧисло повреждённых файлов или корректность содержимого файлов
Фоновая инициализацияСлужебно подготавливает избыточность нового массива или массива после поддерживаемого изменения конфигурацииПериодическую профилактику давно работающего массива

Доступность диагностических данных диска зависит от протокола и пути подключения. У SATA часто доступны ATA S.M.A.R.T.-данные; у SAS применяются SCSI Informational Exceptions и log pages; у NVMe — SMART/Health log и другие журналы NVMe. Набор полей, пороги и смысл vendor-specific атрибутов определяет производитель накопителя. Не переносите пороги ATA-атрибутов на SAS или NVMe и не назначайте единый «безопасный» предел для всех моделей.

S.M.A.R.T. за аппаратным RAID

Аппаратный контроллер нередко скрывает физические диски от ОС. Для мониторинга состояния RAID используйте поддерживаемую утилиту контроллера и её журналы. Прямое чтение S.M.A.R.T. через smartctl возможно только при документированном режиме обращения к конкретному контроллеру, драйверу и типу SATA, SAS или NVMe-диска. Не применяйте найденный в интернете ключ -d без проверки документации именно вашей модели.

Patrol Read, Consistency Check и Background Initialization могут иметь разные названия, расписания, приоритеты, охват дисков и поведение при ошибке у разных семейств контроллеров и версий прошивки. Перед включением автоматического запуска зафиксируйте модель контроллера, OEM-исполнение, версию прошивки, версию утилиты управления и дату проверки документации. Не переносите параметры Dell PERC, HPE Smart Array, Broadcom/MegaRAID или Adaptec SmartRAID между собой.

Проверка с исправлением — не обычный первый шаг

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

Мониторинг программного RAID mdadm в Linux

В mdadm событийный мониторинг и периодическая проверка согласованности — независимые механизмы. Монитор читает события массива и может отправлять почту или запускать программу-обработчик; check запускает операцию ядра над конкретным md-устройством. Создание массива и начальная настройка описаны отдельно в статье «Как создать и настроить программный RAID в Linux с mdadm».

Настройте и проверьте событийный мониторинг mdadm

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

  1. 1
    Снимите текущий статус массива
    Выполните cat /proc/mdstat и mdadm --detail /dev/md0, подставив имя своего массива. Сохраните вывод: в нём нужны состояние, активные члены, spare и текущая синхронизация.
  2. 2
    Задайте получателя событий
    В конфигурации mdadm, используемой дистрибутивом, добавьте MAILADDR для работающего почтового маршрута либо PROGRAM для собственного обработчика. Адрес или программа должны быть доступны службе mdadm, а не только интерактивному пользователю.
  3. 3
    Найдите и проверьте штатный монитор
    Получите список кандидатов командой systemctl list-unit-files | grep -Ei 'mdadm|mdmonitor', затем изучите назначение нужного unit через systemctl cat <имя-unit> и документацию пакета вашего дистрибутива. Включайте только unit, документированный как событийный монитор mdadm, и убедитесь через systemctl status <имя-unit> и journalctl -u <имя-unit>, что не работает второй экземпляр монитора.
  4. 4
    Проверьте канал разовым тестовым событием
    После настройки почты или обработчика выполните mdadm --monitor --scan --test --oneshot. Параметр --oneshot завершает разовую проверку и не оставляет ещё один постоянный монитор. Успех — это не только отсутствие ошибки в консоли: ответственному должно прийти тестовое уведомление с понятным источником, а событие должно быть видно в журнале или системе мониторинга.
/etc/mdadm/mdadm.conf или путь, используемый дистрибутивом
# Пример: укажите реальный адрес работающего почтового маршрута
MAILADDR storage-alerts@example.invalid

# Альтернатива или дополнение: путь к проверенному обработчику событий
# PROGRAM /usr/local/sbin/mdadm-event-handler
Показывает состояние конкретного массива и общий прогресс синхронизации. Замените `/dev/md0` на своё md-устройство.
mdadm --detail /dev/md0 && cat /proc/mdstat
Вывод:
Ищите `State`, список `Active Devices` и `Working Devices`, а при активной задаче — строку с progress/recovery/check в `/proc/mdstat`.

Периодическая проверка mdadm: check, repair и mismatch_cnt

Для md-массива состояние фоновой операции доступно в /sys/block/mdX/md/sync_action. Значение check означает проверку согласованности и подсчёт расхождений без их исправления только на основании результата сравнения. Однако check не гарантирует полностью read-only-поведение: при ошибке чтения штатная обработка ошибки в md может восстановить и записать данные на устройство. Значение repair задаёт режим исправления обнаруженных несоответствий; idle означает отсутствие такой операции. Точное поведение зависит от RAID-уровня, версии ядра и реализации md, поэтому до включения расписания сверьте документацию используемых версий.

Проверяет действие синхронизации, счётчик несоответствий и ход операции для `/dev/md0`.
cat /sys/block/md0/md/sync_action; cat /sys/block/md0/md/mismatch_cnt; cat /proc/mdstat

mismatch_cnt — публикуемый ядром sysfs-счётчик числа секторов, в которых проверка конкретного md-массива обнаружила несоответствие. Это не число файлов, блоков приложения или потерянных записей, и по нему нельзя определить объём повреждённых пользовательских данных. Для RAID с чётностью расхождение означает, что проверяемая избыточность не совпала с пересчитанным значением. Для зеркала счётчик не сообщает, какая копия семантически верна. Сначала зафиксируйте значение, тип массива, состояние дисков, недавние сбои и наличие проверяемой резервной копии.

Организуйте mdadm check без двойного расписания

  1. 1
    Проверьте штатный механизм дистрибутива
    Просмотрите systemctl list-timers --all | grep -Ei 'md|raid|check' и задания cron, поставляемые пакетом mdadm. Если штатная еженедельная проверка уже включена, настройте её по документации дистрибутива и не добавляйте второе расписание.
  2. 2
    Выберите окно
    Оцените длительность прошлых проверок, текущую нагрузку, резервное копирование, Rebuild, миграцию и другие сканирования. Не запускайте проверку в пиковое время без оценки влияния на задержки и I/O.
  3. 3
    Запустите только check
    Для массива без активной конфликтующей операции администратор может запустить printf check > /sys/block/md0/md/sync_action. До запуска убедитесь, что путь относится к нужному массиву, и сохраните исходные sync_action и mismatch_cnt.
  4. 4
    Контролируйте и завершите проверку
    Следите за /proc/mdstat, sync_action, журналом ОС и задержками приложения. После завершения сохраните итоговый mismatch_cnt и не переключайте действие на repair автоматически только потому, что счётчик ненулевой.

Не запускайте repair по шаблону

Команда записи repair в sync_action меняет режим операции. До неё нужны контекст расхождения, сохранённые статусы, пригодная резервная копия и понимание последствий для данного RAID-уровня и версии ядра. При уже возникшем отказе массива действуйте по статье «RAID Degraded, Offline или Failed: диагностика отказа дисков».

Как планировать Patrol Read, Consistency Check и проверку RAID

Не существует общего безопасного расписания для всех RAID. Patrol Read, Consistency Check и mdadm check могут заметно нагружать диски, контроллер и общие пути ввода-вывода. Их период выбирают по длительности полного прохода, допустимому окну обслуживания, профилю нагрузки, возрасту и типу накопителей, требованиям производителя и наличию других задач.

  1. Соберите фактическую длительность первой операции на ненагруженном или согласованном окне и зафиксируйте влияние на задержки.
  2. Разнесите по времени Patrol Read, Consistency Check, mdadm check, резервное копирование, Rebuild, миграцию RAID и тяжёлые задачи приложения.
  3. Назначьте приоритет, который поддерживает именно ваша реализация, только после проверки документации контроллера и прошивки.
  4. Не запускайте новую проверку, если уже идут Rebuild, инициализация, расширение массива или иная фоновая операция, пока документация не описывает безопасное совместное выполнение.
  5. По завершении просмотрите журналы и результаты; незавершённая или регулярно прерываемая задача сама является поводом для диагностики.

Rebuild и Background Initialization — разные процессы

Rebuild восстанавливает избыточность после замены отказавшего диска. Background Initialization относится к подготовке нового массива или поддерживаемому изменению конфигурации. Ни один из процессов не следует считать периодической проверкой уже работающего массива. Порядок замены диска и контроль Rebuild описаны в статье «Замена диска в RAID и Rebuild: порядок действий и контроль».

Сигналы RAID: срочность, фиксация и первое безопасное действие

СигналСрочностьЧто зафиксироватьПервое безопасное действие
Offline логический диск, Failed массив или несколько одновременно исчезнувших дисковКритическаяСтатусы logical и physical drive, enclosure:slot, serial/WWN, события контроллера и корзины, состояние кэша, активные задачиОстановить непроверенные изменения; проверить пригодность резервной копии; не создавать массив, не инициализировать и не выполнять Force Online
Degraded, потеря избыточности, неожиданная остановка или ошибка RebuildВысокаяRAID-уровень, работающие и отсутствующие члены, последний прогресс и причина остановки Rebuild, ошибки оставшихся дисков, журналыУведомить ответственного, сохранить состояние и перейти к процедуре диагностики; не извлекать диск по одному только имени ОС и не перезапускать Rebuild вслепую
Ожидаемый старт RebuildСредняя; высокая, если запуск не был запланирован или выбран неожиданный дискПричину запуска, исходный и целевой диски, enclosure:slot, serial/WWN, состояние массива и начальный прогрессПодтвердить правильность выбранного диска и контролировать прогресс, ошибки оставшихся накопителей и нагрузку
Predictive Failure или PFAВысокаяТочный статус, диагностические журналы, модель, serial/WWN, slot, счётчики и их изменениеСобрать данные, проверить резервную копию, запланировать замену по процедуре; не извлекать диск автоматически
Рост media errors, other errors, ошибок чтения, записи или связиВысокая либо средняя — по скорости роста и влияниюЗначения до и после, время событий, затронутые диски и общий путь подключения, журналы ОС и контроллераСопоставить с другими дисками и инфраструктурой; исключить общую проблему корзины, кабеля, питания или контроллера
cache protection failed, Battery/CacheVault/supercapacitor faultВысокаяПолитику кэша, состояние защиты, dirty/preserved cache, текст и код события, модель и версию прошивкиНе включать Write-Back принудительно; сохранить статусы и действовать по инструкции по BBU и CacheVault
Неожиданный переход Write-Back в Write-ThroughВысокаяСостояние защиты кэша, политику каждого logical drive, события контроллера, производительность до и послеПодтвердить причину по журналу; не обходить защитное ограничение принудительным изменением политики
Patrol Read, Consistency Check или mdadm check завершились с предупреждениемСредняя, повышается при ошибках дисков или потере избыточностиИмя операции, время, охват, режим исправления, результат, журналы, состояние массива до и послеНе включать коррекцию вслепую; проверить резервную копию и документацию конкретной реализации

При критическом событии не меняйте RAID-метаданные наугад

До точной идентификации объекта не извлекайте диск, не запускайте Initialize, Clear Foreign Configuration, Create Virtual Disk, Force Online, принудительную сборку массива или новый Rebuild. При dirty или preserved cache и отсутствии непосредственной угрозы людям или оборудованию не выполняйте плановое обесточивание сервера и не заменяйте контроллер без документированной процедуры сохранения или восстановления кэша. Для состояний Foreign Configuration используйте статью «Foreign Configuration в RAID: когда импортировать, когда очищать и как не потерять массив».

Что сохранить перед диагностикой

  • Время события, источник, полный текст, код и уровень срочности уведомления.
  • Модель контроллера, OEM-исполнение, версия прошивки, драйвер и версия утилиты управления.
  • RAID-уровень, состояние и идентификатор логического диска; список физических дисков с enclosure:slot, serial/WWN, моделью и состоянием.
  • Состояние кэша, политика записи, BBU/CacheVault/суперконденсатора, dirty или preserved cache.
  • Журналы контроллера, BMC/iDRAC/iLO при наличии, системный журнал ОС и журналы накопителей, доступные через поддерживаемый путь.
  • Активные фоновые операции: Rebuild, Patrol Read, Consistency Check, Background Initialization, mdadm sync_action; их прогресс, приоритет и время старта.
  • Статус последней резервной копии и свидетельство тестового восстановления, а не только отметка о завершении задания.

RAID не заменяет независимую резервную копию. В регламенте достаточно регулярно подтверждать два факта: резервная копия существует для нужных данных и её восстановление периодически проверяется в подходящем тестовом контуре. Детали проектирования копирования разобраны в статье «Почему RAID — не резервное копирование: защита данных сервера».

Проверяйте не только настройки, но и доставку уведомлений

Включите тест оповещений в регламент

  1. 1
    Определите получателя и время реакции
    Для каждого класса событий назначьте ответственного, резервного получателя и канал: почта, webhook, тикет-система или централизованный мониторинг. Уведомление без владельца не является рабочим мониторингом.
  2. 2
    Отправьте безопасное тестовое сообщение
    Используйте функцию test в самом средстве мониторинга. Для разового теста mdadm подходит mdadm --monitor --scan --test --oneshot; для аппаратного RAID используйте только документированный тест механизма оповещений контроллера или платформы, без имитации отказа рабочего диска.
  3. 3
    Подтвердите весь маршрут
    Проверьте создание события у источника, прохождение через почтовый ретранслятор или webhook, получение ответственным и отображение понятного имени сервера и массива. Отсутствие ошибки отправителя не доказывает доставку.
  4. 4
    Повторяйте после изменений
    Повторите тест после изменения адресатов, почтового ретранслятора, webhook, системы мониторинга, обновления контроллера, переустановки mdadm или перезагрузки, если она меняла службы.

Термины в статье

Реализация RAID, в которой специализированный контроллер формирует логические диски и выполняет операции массива. Наличие и защита кэша зависят от модели.
Грязный кэш содержит изменённые блоки, ещё не записанные в постоянное хранилище. Такие блоки нельзя безопасно отбросить до их сброса.
Состояние отказоустойчивого RAID-массива, потерявшего часть избыточности, но сохраняющего доступ, пока сочетание отказов допустимо для его уровня и раскладки.
Кэш со сквозной записью — режим, в котором кэш не подтверждает запись раньше нижележащего хранилища и не оставляет подтверждённые данные только в своей энергозависимой памяти.
Логический диск — блочное устройство, которое RAID-контроллер или программная RAID-подсистема предоставляет хосту как отдельный накопитель.
Миграция RAID-уровня — преобразование существующего массива в другой RAID-уровень без выгрузки данных, если эту операцию поддерживает контроллер.
Системная служба — программный компонент, которым ОС управляет как логической единицей для фонового выполнения задач или предоставления функций программам и пользователям.
Накопитель энергии высокой мощности, применяемый для кратковременного питания кэша RAID-контроллера. При сбое питания он сохраняет данные до записи во флеш-память.
Физический диск — отдельный HDD, SSD или иной накопитель, распознанный RAID-контроллером как член массива либо как независимое устройство.
Фоновая инициализация — формирование или проверка RAID-контроллером данных избыточности нового массива без отключения логического диска.
Избыточные контрольные данные, вычисляемые из блоков одной полосы RAID. Один блок чётности защищает от отказа одного диска, два независимых блока RAID 6 — от отказа двух.
Adaptec SmartRAID — семейство аппаратных RAID-контроллеров Microchip для SAS/SATA, а в новых tri-mode-моделях — также для NVMe-накопителей.
Аккумуляторный модуль, поддерживающий питание энергозависимого кэша RAID-контроллера при сбое питания до восстановления питания и записи данных на диски.
CacheVault — технология защиты кэша записи RAID-контроллера, сохраняющая во флеш-память подтверждённые хосту, но ещё не записанные на диски данные при потере питания.
Consistency Check — фоновая проверка согласованности избыточности RAID: зеркальных копий либо рассчитанной и записанной чётности; расхождения могут исправляться.
Cron — служба-планировщик в Unix-подобных ОС, запускающая команды по расписаниям из таблиц crontab, обычно с минутной дискретностью.
Семейство RAID-решений Dell для серверов PowerEdge: аппаратные контроллеры PERC H и программные PERC S. Возможности и совместимость зависят от модели и поколения платформы.
Failed — статус физического накопителя, который RAID-контроллер признал отказавшим и перестал использовать для штатного ввода-вывода в составе массива.
Состояние, при котором RAID-контроллер считает найденную на дисках конфигурацию массива не зарегистрированной или не совпадающей с текущей. Её проверяют и импортируют либо очищают.
Семейство аппаратных и программных RAID-решений HPE для локальных SAS/SATA-накопителей и, в поддерживаемых tri-mode-конфигурациях, NVMe.
Утилита командной строки Linux для создания, сборки, мониторинга и изменения программных RAID-массивов подсистемы MD.
Семейство аппаратных RAID-контроллеров Broadcom, которые объединяют накопители в массивы и предоставляют ОС логические диски, обрабатывая RAID на самом контроллере.
NVMe — протокол обмена командами с энергонезависимыми накопителями, оптимизированный для параллельного ввода-вывода; локальные NVMe-SSD обычно подключаются по PCIe.
Offline — зависящий от реализации статус накопителя или виртуального диска RAID: первый исключён контроллером из работы, второй недоступен хосту.
Patrol Read — фоновое сканирование накопителей RAID-контроллером для поиска скрытых ошибок чтения. В избыточном массиве контроллер может восстановить повреждённые блоки.
PFA — анализ предвестников отказа оборудования по диагностическим данным. Он формирует предупреждение, чтобы заменить компонент до фактической неисправности.
Predictive Failure — диагностический статус накопителя, указывающий на признаки вероятного отказа по SMART или данным контроллера до фактической недоступности диска.
Технология объединения нескольких накопителей в логические блочные устройства для повышения производительности и/или отказоустойчивости в зависимости от RAID-уровня.
RAID 1 — уровень RAID с зеркалированием данных на двух или более дисках. Полезная ёмкость равна ёмкости наименьшего участника, а доступ сохраняется, пока исправна хотя бы одна копия.
Устройство или модуль, который формирует RAID-массивы из накопителей и предоставляет ОС логические диски, управляя размещением данных, отказами и восстановлением избыточности.
Буфер быстрой памяти между хостом и накопителями RAID, используемый для кэширования чтения и записи. Может снижать задержку и повышать производительность ввода-вывода.
RAID-уровень — схема размещения данных и избыточности по накопителям массива, определяющая полезную ёмкость, отказоустойчивость и характеристики ввода-вывода.
Процесс восстановления избыточности массива после замены отказавшего диска: контроллер вычисляет и записывает на новый диск недостающие данные из остальных дисков.
S.M.A.R.T. — технология самодиагностики накопителей, собирающая показатели состояния и ошибок. Она помогает выявлять признаки деградации диска до отказа.
SAS — последовательный интерфейс и набор протоколов SCSI для подключения накопителей, поддерживающий адресацию устройств, экспандеры и обычно двухпортовое подключение дисков.
Устройство коммутации SAS, расширяющее число подключаемых накопителей относительно числа портов контроллера. Передаёт SAS-трафик между инициаторами и целевыми устройствами.
SATA — последовательный интерфейс подключения HDD, SSD и оптических приводов; в обычной прямой схеме один порт контроллера соединён с одним накопителем.
Политика кэша RAID-контроллера: запись подтверждается после помещения данных в кэш, а на накопители переносится позже. Кэш требует защиты от потери питания.

Вопросы по теме

Все вопросы и ответы

Гарантирует ли S.M.A.R.T., что диск не выйдет из строя?

Нет. S.M.A.R.T. и журналы диска показывают доступные диагностические признаки и историю ошибок, но не предсказывают отказ с гарантией. Они также не подтверждают правильность RAID-чётности, зеркальных копий или пользовательских файлов. Набор показателей и смысл vendor-specific атрибутов зависят от модели и типа накопителя.

Можно ли извлекать диск, ориентируясь только на имя /dev/sdX?

Нет. Имя /dev/sdX может измениться после перезагрузки, перестановки дисков или смены порядка их обнаружения. Перед извлечением нужно сопоставить физический диск с неизменным адресом enclosure:slot, серийным номером или WWN. Для mdadm дополнительно используйте /dev/disk/by-id/ и подтверждённое членство диска в массиве.

Означает ли mismatch_cnt в mdadm повреждённые файлы?

Нет. mismatch_cnt показывает число секторов, где проверка конкретного md-массива обнаружила несоответствие, а не число файлов, блоков приложения или потерянных записей. Для RAID с чётностью это расхождение между избыточностью и пересчитанным значением; для зеркала счётчик не определяет, какая копия данных семантически верна.

Можно ли после mdadm check сразу запускать repair?

Нет, не автоматически. Ненулевой mismatch_cnt сам по себе не объясняет причину расхождения и не указывает правильную версию данных. До repair нужно сохранить статусы и журналы, учесть RAID-уровень, недавние сбои и состояние дисков, проверить пригодность резервной копии и понять последствия для используемой версии md и ядра.

Нужно ли сразу менять диск при Predictive Failure?

Зависит от процедуры, но игнорировать сигнал нельзя. При Predictive Failure сначала зафиксируйте точный статус, журналы, модель, serial/WWN, слот и изменение счётчиков, затем проверьте резервную копию и запланируйте замену. Не извлекайте диск автоматически: предупреждение требует диагностики и идентификации физического накопителя.

Чем Rebuild отличается от Background Initialization?

Rebuild восстанавливает избыточность после замены отказавшего диска. Background Initialization служебно подготавливает избыточность нового массива или массива после поддерживаемого изменения конфигурации. Это разные процессы: Background Initialization не является периодической проверкой давно работающего массива, а Rebuild не заменяет профилактическую проверку согласованности.