Восстановление RAID-массива mdadm после сбоя диска

В статье «Настройка программного RAID в Linux с помощью mdadm» мы разобрали базовый сценарий замены отказавшего диска тот случай, когда всё идёт штатно: диск помечен faulty, вы его убираете и добавляете новый. Но на практике встречаются ситуации серьёзнее: массив не собирается после перезагрузки, суперблок повреждён, отказало сразу несколько дисков, или сервер и вовсе не загружается из-за проблем с корневым массивом.

В этой статье разберём, как диагностировать и восстанавливать RAID-массив mdadm в нештатных ситуациях: работу в degraded-режиме, принудительную сборку массива, восстановление после случайного удаления суперблока и типичные ошибки, с которыми сталкиваются администраторы.

Важно перед началом работы: если на дисках массива есть критически важные данные и вы не уверены в своих действиях, по возможности сначала снимите посекторные образы дисков (dd или ddrescue) и работайте с копиями, а не с оригиналами — это стандартная практика при восстановлении данных, которая защитит вас от необратимых ошибок.

Шаг 1: диагностика что именно произошло

Прежде чем что-либо чинить, соберите полную картину происходящего.

Проверьте состояние массива:

bash

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

Обратите внимание на строку состояния: clean всё в порядке, degraded массив работает, но без резервирования (не хватает одного или нескольких дисков), inactive массив не собран.

Проверьте суперблоки на самих дисках (метаданные RAID хранятся на каждом диске отдельно):

bash

sudo mdadm --examine /dev/sdb
sudo mdadm --examine /dev/sdc
sudo mdadm --examine /dev/sdd

Эта команда покажет, видит ли mdadm на диске корректный суперблок массива, его роль (Active, Spare, Faulty) и номер события (Events) по нему можно понять, какой из дисков «отстал» от остальных по актуальности данных.

Проверьте системные логи на предмет ошибок диска на аппаратном уровне:

bash

sudo dmesg | grep -i -E "sd[a-z]|ata|md0"
sudo journalctl -k | grep -i -E "error|fail" | tail -50

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

Сценарий 1: массив работает в degraded-режиме

Это самый частый и наименее опасный случай один диск отказал (или отсутствует), но массив продолжает работать благодаря избыточности (RAID 1/5/6/10).

1. Убедитесь, какой именно диск выпал из массива, сравнив список дисков в системе (lsblk) со списком в mdadm --detail /dev/md0.
2. Если диск физически неисправен — замените его и добавьте новый в массив:

bash

   sudo mdadm /dev/md0 --add /dev/sdX

3. Если диск оказался исправен, но по какой-то причине выпал из массива (например, после единичного сбоя контроллера или временной ошибки), можно попробовать вернуть его обратно без физической замены:

bash

   sudo mdadm /dev/md0 --re-add /dev/sdX

Команда --re-add работает быстрее полного ребилда, если mdadm распознаёт, что данные на диске всё ещё в целом актуальны (bitmap resync), но применять её стоит только если вы уверены, что диск исправен. 4. Следите за прогрессом восстановления через cat /proc/mdstat.

Сценарий 2: массив не собирается после перезагрузки

Если после перезагрузки сервера массив /dev/md0 отсутствует или не активен, попробуйте собрать его вручную.

Стандартная сборка по конфигурации:

bash

sudo mdadm --assemble --scan

Если это не помогло, соберите массив явно, указав конкретные диски:

bash

sudo mdadm --assemble /dev/md0 /dev/sdb /dev/sdc /dev/sdd

Если mdadm отказывается собирать массив из-за расхождений между дисками (например, разный номер Events в выводе --examine), можно прибегнуть к принудительной сборке:

bash

sudo mdadm --assemble --force /dev/md0 /dev/sdb /dev/sdc /dev/sdd

Осторожно: флаг --force заставляет mdadm собрать массив, даже если состояние дисков не полностью синхронизировано, беря за основу диск с наиболее актуальным номером события. Это может привести к неконсистентности данных на «отставшем» диске. Используйте --force как крайнюю меру, когда штатная сборка невозможна, и по возможности заранее снимите образы дисков.

После принудительной сборки обязательно проверьте файловую систему на массиве, прежде чем монтировать её на запись:

bash

sudo fsck -n /dev/md0

Флаг -n запускает проверку в режиме «только чтение», без внесения изменений это позволяет оценить масштаб проблемы, не рискуя усугубить её.

Сценарий 3: повреждён или отсутствует суперблок RAID

Если суперблок массива на одном из дисков поврежён или стёрт (например, диск случайно был отформатирован или использован в другом массиве), команда mdadm --examine покажет, что на этом диске суперблок отсутствует.

В этом случае, если остальные диски массива в порядке, можно пересоздать суперблок на замену для «пустого» диска, добавив его в массив как новый — операция --add, описанная в сценарии 1, сама создаст корректный суперблок и запустит ребилд.

Если же суперблоки повреждены сразу на нескольких дисках, а актуальность данных на каждом из них неизвестна, ситуация значительно сложнее в такой ситуации, если данные критически важны, разумнее привлечь специалистов по восстановлению данных, чем экспериментировать с принудительной пересборкой массива вручную.

Сценарий 4: сервер не загружается из-за проблем с корневым массивом

Если RAID-массив используется под корневой раздел (/), а сервер не загружается, потребуется загрузиться с внешнего носителя (Live-образ Linux) и провести диагностику и сборку массива из этой временной среды, а затем при необходимости обновить initramfs и загрузчик после устранения проблемы, чтобы избежать повторения ситуации при следующей загрузке.

bash

# Пример работы из Live-окружения:
sudo mdadm --assemble --scan
sudo mount /dev/md0 /mnt
sudo chroot /mnt
sudo update-initramfs -u   # Debian/Ubuntu
sudo dracut -f              # RHEL-семейство

Типичные ошибки при восстановлении mdadm

• Игнорирование номера Events при сборке нескольких дисков. Если диски сильно разошлись по числу событий, принудительная сборка может привести к потере данных на «отставшем» диске всегда проверяйте mdadm --examine перед использованием --force.
• Монтирование массива на запись сразу после принудительной сборки, без предварительной проверки файловой системы командой fsck -n.
• Замена диска без предварительной диагностики если проблема была не в диске, а, например, в кабеле, контроллере или блоке питания, замена диска не решит проблему, и новый диск тоже может «отвалиться» из массива.
• Отсутствие актуального mdadm.conf без него массив может собраться в другом порядке дисков или не собраться автоматически вовсе. Не забывайте обновлять конфигурацию, как описано в статье про настройку mdadm.
• Работа без резервной копии данных, когда она была возможна — RAID снижает риск потери данных, но не исключает его полностью, особенно при множественных отказах.

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

Чем отличаются --add и --re-add? --add добавляет диск в массив как полностью новый, требующий полного ребилда с нуля. --re-add используется для диска, который уже был частью этого массива и, вероятно, содержит частично актуальные данные в этом случае mdadm может выполнить более быстрое частичное восстановление вместо полного ребилда.

Безопасно ли использовать флаг —force? Он безопасен только в том случае, если вы понимаете, какой диск в массиве наиболее актуален, и осознанно жертвуете данными на отставших дисках. Без анализа вывода mdadm --examine использовать --force не рекомендуется.

Можно ли восстановить данные, если массив RAID 5 потерял сразу два диска? Штатными средствами mdadm нет, массив RAID 5 рассчитан на отказ только одного диска. В таких случаях (если данные критически важны) стоит обращаться в специализированные лаборатории восстановления данных, которые работают напрямую с содержимым дисков в обход логики RAID-массива.

Как понять, что причина в диске, а не в кабеле или контроллере? Проверьте dmesg и journalctl на предмет повторяющихся ошибок именно этого физического устройства. Если ошибки продолжаются даже после подключения диска к другому порту/кабелю, вероятная причина сам накопитель.

Заключение

Восстановление RAID-массива mdadm в нештатных ситуациях требует спокойной и последовательной диагностики: сначала понять, что произошло (mdstat, --detail, --examine, логи), затем выбрать наименее рискованный путь восстановления, и только в крайнем случае прибегать к принудительной сборке (--force), заранее оценив, каким диском при этом придётся пожертвовать. И, как всегда с RAID, чем важнее данные, тем больше смысла заранее иметь их резервную копию, а не полагаться исключительно на отказоустойчивость массива.