RAID1 в Linux на mdadm: мониторинг, замена диска и rebuild с уведомлениями

Linux software RAID на mdadm до сих пор остаётся рабочей «классикой»: минимум зависимости от контроллеров, понятная диагностика и предсказуемое восстановление. Но в бою важны детали: как быстро заметить degraded array, как корректно выполнить replace failed disk, как контролировать raid rebuild и не забыть про grub on raid, чтобы сервер вообще загрузился после замены диска.

Ниже — практичный чек-лист для RAID1: диагностика, замена диска, rebuild, типовые ошибки и рабочая схема мониторинга: mdadm monitor (systemd), email-уведомления и smartctl / smartd для ранних симптомов деградации.

Быстрая шпаргалка: что проверить в первую минуту

Если пришёл алерт или заметили странности (I/O errors, подвисания, переход ФС в read-only), начинайте с короткого набора команд:

cat /proc/mdstat
sudo mdadm --detail /dev/md0
sudo lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL
sudo dmesg -T | tail -n 200

В /proc/mdstat обычно достаточно трёх признаков:

• статус массива: [UU] — оба диска в строю, [U_] или [_U] — degraded;
• идёт ли восстановление: строки про recovery/resync, процент, скорость;
• какие устройства участвуют (например, sda1[0] sdb1[1]).

Деградация RAID1 — это не «немедленно выключить сервер». Это «быстро понять, какой диск умирает, и не допустить второй отказ во время rebuild».

Как понять, какой диск «плохой», и не перепутать при замене

Самая дорогая ошибка при восстановлении mdadm RAID1 — перепутать диски и вынуть/обнулить «живой». Поэтому сначала увязываем md-устройство с конкретными физическими дисками (серийники, модель) и состоянием, которое видит RAID.

1) Посмотреть детально состояние массива

sudo mdadm --detail /dev/md0

В выводе важны:

• State (например, clean, degraded);
• таблица членов массива и колонка State у каждого;
• какой именно раздел (например, /dev/sdb1) помечен как faulty, removed или отсутствует.

2) Привязать /dev/sdX к «железу»

Минимально — модель и серийник:

sudo lsblk -d -o NAME,SIZE,MODEL,SERIAL
sudo udevadm info --query=property --name=/dev/sda | grep -E 'ID_MODEL=|ID_SERIAL='
sudo udevadm info --query=property --name=/dev/sdb | grep -E 'ID_MODEL=|ID_SERIAL='

Если сервер с hot-swap и бэкплейном, помогает список by-id (он обычно стабильнее, чем sdX):

ls -l /dev/disk/by-id/ | grep -E 'ata-|scsi-|nvme-'

3) Подтвердить подозрения SMART-ом

Для SATA/SAS:

sudo smartctl -a /dev/sda
sudo smartctl -a /dev/sdb

Для NVMe:

sudo smartctl -a /dev/nvme0
sudo smartctl -a /dev/nvme1

В контексте «диск сыпется» обычно выстреливают:

• перераспределённые/ожидающие/неисправимые блоки (reallocated/pending/unrecoverable);
• быстрый рост ошибок/таймаутов в логах;
• для NVMe — Media and Data Integrity Errors, Critical Warning, рост Error Information Log Entries.

Процедура замены failed disk в mdadm RAID1 (пошагово)

Сценарий ниже подходит для большинства установок: два диска, GPT, RAID1 на разделах. Примеры для массива /dev/md0 и проблемного члена /dev/sdb1. Подстройте имена устройств под свою систему.

Шаг 0. Убедитесь, что у вас есть бэкап

RAID — не бэкап. Перед агрессивными действиями (особенно если второй диск тоже «под вопросом») убедитесь, что бэкап актуален и вы реально умеете из него восстанавливаться.

Шаг 1. Пометить проблемный диск как failed и удалить из массива

Иногда mdadm уже помечает диск как faulty. Если нет — делаем вручную:

sudo mdadm /dev/md0 --fail /dev/sdb1
sudo mdadm /dev/md0 --remove /dev/sdb1

После этого cat /proc/mdstat должен показывать degraded ([U_] или [_U]).

Шаг 2. Физическая замена диска (или переподключение)

Если hot-swap — меняем диск на горячую. Если нет — выключение, замена, включение. После появления нового диска в системе проверьте, что вы действительно работаете с ним:

sudo lsblk -d -o NAME,SIZE,MODEL,SERIAL
sudo wipefs -n /dev/sdb

Ключ -n у wipefs делает только просмотр. Удалять сигнатуры нужно осознанно и только на правильном диске.

Шаг 3. Клонировать разметку с живого диска на новый (GPT)

На практике проще всего скопировать GPT с исправного диска на новый:

sudo sgdisk -R=/dev/sdb /dev/sda
sudo sgdisk -G /dev/sdb
sudo partprobe /dev/sdb
sudo lsblk /dev/sdb

sgdisk -R копирует таблицу разделов, -G генерирует новые GUID, чтобы избежать конфликтов. Если у вас MBR/нестандартная схема — шаги будут отличаться, но логика та же: новый диск должен получить корректные разделы.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Шаг 4. Добавить новый раздел в RAID и запустить rebuild

Добавляем соответствующий раздел (например, /dev/sdb1) обратно в массив:

sudo mdadm /dev/md0 --add /dev/sdb1
watch -n 1 cat /proc/mdstat

Это и есть запуск raid rebuild (в терминологии mdadm это чаще recovery или resync). Скорость зависит от размера массива, нагрузки и лимитов ядра.

Шаг 5. Контроль и завершение rebuild

Два самых полезных статуса:

cat /proc/mdstat
sudo mdadm --detail /dev/md0

После завершения восстановление исчезает из /proc/mdstat, а массив становится clean и [UU].

Тюнинг скорости rebuild и влияние на прод

Во время восстановления RAID1 обычно растёт latency диска и падает производительность приложений. Есть два честных режима: «быстрее восстановить и пережить» или «не убить прод, пусть дольше».

Проверить текущие лимиты ресинка

cat /proc/sys/dev/raid/speed_limit_min
cat /proc/sys/dev/raid/speed_limit_max

Временно повысить или понизить лимиты

sudo sysctl -w dev.raid.speed_limit_min=50000
sudo sysctl -w dev.raid.speed_limit_max=200000

Значения — в КБ/с. На перегруженной БД иногда лучше снизить лимит, чтобы не получить лавину таймаутов. В ночное окно — наоборот, поднять.

Если во время rebuild второй диск начинает показывать ошибки SMART или I/O errors, остановитесь и оцените риски. Иногда правильнее сначала снять поблочный образ/бэкап, чем «додавить» восстановление ценой потери массива.

GRUB после замены диска: как не получить не загружающуюся систему

RAID1 защищает данные, но не всегда защищает загрузчик. Частый сценарий: система годами грузилась с первого диска, второй был «просто зеркалом». После замены/перестановки дисков порядок загрузки меняется — и сервер не стартует.

Практическое правило: после замены диска сделайте новый диск загрузочным тоже. Команды зависят от режима загрузки (BIOS/UEFI).

Вариант 1: BIOS (legacy) + GRUB

Устанавливаем GRUB в boot-sector диска:

sudo grub-install /dev/sdb
sudo update-grub

Вариант 2: UEFI

В UEFI обычно есть EFI System Partition (ESP). Он часто не находится в mdraid (хотя варианты бывают), и его нужно синхронизировать отдельно. Сначала проверьте, смонтирован ли ESP как /boot/efi и где он находится:

findmnt /boot/efi
lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINTS

Дальше общий план такой:

1. убедиться, что на новом диске есть ESP нужного размера и типа;
2. при необходимости создать на ESP файловую систему;
3. смонтировать ESP нового диска во временную точку и скопировать содержимое текущего ESP;
4. выполнить установку загрузчика для UEFI и проверить наличие записи в NVRAM.

Универсальной «одной команды» нет: отличия зависят от дистрибутива, разметки и того, как именно настраивался GRUB. Если у вас инфраструктура на нескольких серверах, полезно зафиксировать эти шаги в runbook (и держать его рядом с доступами к консоли).

mdadm monitor: уведомления о degraded array через email и systemd

Мониторинг mdadm — быстрый выигрыш: деградация массива должна приходить алертом, а не обнаруживаться «случайно в /proc/mdstat». Классический путь — mdadm --monitor плюс конфиг /etc/mdadm/mdadm.conf (Debian/Ubuntu) или /etc/mdadm.conf (RHEL-подобные).

1) Убедиться, что массив описан в конфиге

Соберите актуальные строки из системы:

sudo mdadm --detail --scan

Проверьте, что этот вывод добавлен в конфиг mdadm. Это помогает и при загрузке, и в мониторинге.

2) Настроить адрес для уведомлений

В конфиге mdadm обычно используется директива MAILADDR. Пример:

MAILADDR admin@example.local

На сервере должен быть настроен MTA (локальная доставка или relay). Иначе mdadm честно «попытается», но письма не улетят.

3) Включить systemd-юнит мониторинга

В разных дистрибутивах имена сервисов отличаются. Начните с поиска:

systemctl list-unit-files | grep -E 'mdadm|mdmonitor'

Часто встречаются mdadm-monitor.service или mdmonitor.service. Включение обычно такое:

sudo systemctl enable --now mdadm-monitor.service
sudo systemctl status mdadm-monitor.service

Если нужно быстро понять, что происходит:

sudo journalctl -u mdadm-monitor.service -n 200 --no-pager

4) Проверить, что письма реально уходят

Полноценный тест деградации на проде рискованный, но доставку почты с хоста проверить можно:

echo 'mdadm monitor test' | mail -s 'test mail from server' admin@example.local

Если команды mail нет — установите mailutils/bsd-mailx (название пакета зависит от дистрибутива).

SMART-мониторинг: признаки до того, как RAID станет degraded

mdadm фиксирует проблему, когда диск уже начал «отваливаться» на уровне I/O или был исключён из массива. SMART часто предупреждает раньше. Поэтому нормальная схема мониторинга для software RAID — это связка: события mdadm + здоровье дисков через smartd.

Если сервер крутится на VDS, RAID1 на mdadm обычно неактуален (диски виртуальные, и отказоустойчивость обеспечивается на стороне платформы). Зато для выделенных серверов или собственных узлов mdadm+SMART остаётся очень практичной связкой.

Разовая проверка SMART (быстро)

sudo smartctl -H /dev/sda
sudo smartctl -H /dev/sdb

Этого мало для мониторинга, но полезно как быстрый «health check».

Самотесты: короткий и длинный

Запуск тестов (SATA/SAS):

sudo smartctl -t short /dev/sda
sudo smartctl -t long /dev/sda

Потом смотрим результаты:

sudo smartctl -a /dev/sda | sed -n '1,120p'
sudo smartctl -a /dev/sda | grep -E 'Self-test|error|fail' -i

Длинные тесты на больших дисках идут часами и создают нагрузку — планируйте окно, особенно если параллельно есть rebuild.

Включить регулярный мониторинг smartd

Обычно используется smartd из пакета smartmontools: он запускает тесты по расписанию и шлёт уведомления. Для software RAID это просто — диски видны как обычные /dev/sdX или /dev/nvmeX.

systemctl status smartd.service
sudo systemctl enable --now smartd.service

Типовые проблемы при восстановлении RAID1 и как их обойти

Новый диск не добавляется: «device busy» или «wrong UUID»

Частая причина — «хвосты» старых метаданных/сигнатур. Сначала ещё раз убедитесь, что это правильный диск. Далее проверьте:

sudo wipefs -n /dev/sdb
sudo mdadm --examine /dev/sdb1

Если остались md-метаданные от старого массива, иногда нужно удалить superblock (только когда вы уверены, что это новый/пустой член):

sudo mdadm --zero-superblock /dev/sdb1

Диск добавился, но sync не стартует

Проверьте три вещи:

• нет ли ошибок I/O по новому диску;
• нет ли паузы ресинка;
• не попали ли вы в ситуацию, когда массив «думает», что данные актуальны (например, из-за особенностей bitmap и предыдущих состояний).

cat /proc/mdstat
sudo mdadm --detail /dev/md0
sudo dmesg -T | tail -n 200

Система не грузится после замены диска

Почти всегда это история про загрузчик или UEFI-записи. План действий:

• проверить порядок загрузки в BIOS/UEFI;
• загрузиться в rescue/Live, собрать массив mdadm --assemble --scan;
• выполнить установку GRUB на нужный диск (и синхронизацию ESP для UEFI).

Если под рукой нет «спасательного» носителя, заранее держите в регламенте, где взять rescue и какие команды выполнять для вашего дистрибутива. В качестве примера подхода к инфраструктурным заметкам может пригодиться статья про разворачивание k3s на сервере: полезно иметь так же чёткий список команд для аварийных сценариев хранения.

Проверка «после работ»: что должно быть в норме

После успешного восстановления сделайте короткий acceptance-чек:

• cat /proc/mdstat показывает [UU] и нет активного recovery/resync;
• mdadm --detail /dev/md0 — State: clean;
• SMART нового диска без ошибок, температура и счётчики выглядят адекватно;
• GRUB установлен на оба диска (или для UEFI ESP корректно синхронизирован);
• включены службы мониторинга и вы уверены, что email-алерты доставляются.

Идея для боевого регламента (runbook)

Чтобы каждый раз не вспоминать нюансы, заведите внутренний регламент на одну страницу:

• какие массивы есть и где они смонтированы;
• какой диск соответствует какому слоту/серийнику;
• точная процедура замены для вашей разметки (BIOS/UEFI);
• куда приходят уведомления mdadm и smartd;
• какие лимиты rebuild приемлемы для вашего продакшена.

Для mdadm RAID1 это особенно полезно: действия простые, но цена ошибки (перепутать диск, забыть загрузчик, пропустить деградацию второго диска) — высокая.