Miklix

Замена неисправного диска в массиве mdadm в Ubuntu

Опубликовано: 15 февраля 2025 г. в 22:02:33 UTC
Последнее обновление: 12 января 2026 г. в 08:50:02 UTC

Если вы столкнулись с неприятной ситуацией — поломкой жесткого диска в RAID-массиве mdadm — в этой статье объясняется, как правильно заменить его в системе Ubuntu.


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

Replacing a Failed Drive in an mdadm Array on Ubuntu

Информация в этом сообщении основана на Ubuntu 18.04 и версии mdadm, включенной в ее репозитории; на момент написания это была версия v4.1-rc1. Она может быть или не быть актуальна для других версий.

Недавно у меня внезапно вышел из строя жесткий диск на домашнем файловом сервере, состоящем из девяти дисков в массиве RAID-6 mdadm. Это всегда пугает, но, к счастью, мне удалось быстро найти замену, которую доставили уже на следующий день, так что я смог начать восстановление.

Признаюсь, я немного пожалел средств при первоначальной настройке файлового сервера; только два диска являются настоящими NAS-дисками (Seagate IronWolf), а остальные — настольными (Seagate Barracuda). Неудивительно, что именно один из настольных дисков вышел из строя (хотя и после почти трех лет работы). Он был полностью неработоспособен; после переноса его в USB-корпус для настольного компьютера из него доносился только неприятный щелкающий звук, и ни Ubuntu 20.04, ни Windows 10 не смогли его обнаружить.

Ну что ж, перейдём к замене (и да, новый диск, который я купил, был IronWolf, урок усвоен) — как бы страшно ни было потерять диск в работающем массиве, ещё страшнее, если вы не знаете правильной процедуры его замены. Это не первый раз, когда мне приходится заменять вышедший из строя диск в массиве mdadm, но, к счастью, это настолько редкое явление, что мне обычно приходится искать правильные команды. На этот раз я решил составить собственное небольшое руководство для дальнейшего использования.

Итак, прежде всего, когда вы получаете это ужасное электронное письмо о сбое от mdadm, вам нужно определить, какой диск вышел из строя. Конечно, оно покажет вам имя устройства (в моем случае /dev/sdf), но, вероятно, не сразу понятно, какой именно физический диск вышел из строя, поскольку эти имена могут меняться при загрузке системы.

Если вы даже не уверены, какое именно устройство вышло из строя, вы можете использовать следующую команду, чтобы это выяснить (замените /dev/md0 на название вашего RAID-устройства):

mdadm -–query -–detail /dev/md0

Как уже упоминалось, в моем случае это был /dev/sdf, поэтому давайте продолжим с этого.

Затем вы можете попытаться найти серийный номер неисправного диска, выполнив следующую команду:

smartctl -–all /dev/sdf | grep -i 'Serial'

(Если smartctl не найден, вам необходимо установить пакет smartmontools в Ubuntu)

Затем серийный номер можно сравнить с серийными номерами на физической этикетке накопителей, чтобы определить, какой из них вышел из строя.

Однако на этот раз мне не повезло. Жесткий диск полностью вышел из строя и даже отказался выдавать данные SMART или другую информацию, включая серийный номер.

Поскольку у меня был физический доступ к серверу (что, я полагаю, действительно необходимо, если вы собираетесь самостоятельно заменять физический диск ;-)) и сервер работал, когда диск вышел из строя (и продолжал нормально работать благодаря резервированию RAID-6), я прибегнул к очень примитивному, но на самом деле весьма эффективному и очевидному методу: просто скопировал большой файл на сервер и посмотрел, какой индикатор жесткого диска не мигает. Через несколько секунд я определил виновника.

Прежде чем извлекать физический диск, целесообразно официально уведомить mdadm о своем намерении, выполнив следующую команду (замените имена устройств на свои собственные, если это необходимо):

mdadm -–manage /dev/md0 -–remove /dev/sdf1

В случае успеха mdadm ответит сообщением о том, что диск был "удален без подключения к серверу", по-видимому, потому что виртуальное RAID-устройство в данный момент фактически запущено.

Если возникает ошибка, похожая на «устройство или ресурс заняты», возможно, mdadm не зарегистрировал диск как полностью вышедший из строя. Чтобы это произошло, выполните следующую команду (опять же, не забудьте заменить имена устройств на свои собственные, если это необходимо):

mdadm --manage /dev/md0 --fail /dev/sdf

После этого вы сможете удалить устройство из массива с помощью предыдущей команды.

Теперь пришло время заменить жесткий диск. Если вы действительно, действительно – очень-очень – уверены, что ваша машина и контроллер поддерживают горячую замену, вы можете сделать это, не выключая машину. Это был бы оптимальный вариант для критически важных производственных систем, работающих на настоящем, качественном серверном оборудовании, которое, как вы точно знаете, с этим справится. Мой домашний файловый сервер основан на материнской плате потребительского класса с парой малоизвестных SATA-контроллеров в слотах PCIe для обеспечения большего количества SATA-портов.

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

Прежде чем это делать, рекомендуется закомментировать строку с RAID-устройством в файле /etc/fstab, чтобы Ubuntu не пыталась автоматически смонтировать его при следующей загрузке, поскольку это может привести к зависанию и принудительному переходу в режим восстановления из-за ухудшения состояния RAID-массива. Это может не быть большой проблемой, если речь идёт о настольной системе, но я использую этот сервер без монитора и клавиатуры, поэтому это создаст некоторые неудобства.

После загрузки компьютера с установленным новым диском используйте команду lsblk или другой способ для его идентификации. Если вы ничего больше не меняли, он, вероятно (но не обязательно), получит то же имя, что и замененный диск. В моем случае так и произошло, поэтому новый диск также называется /dev/sdf.

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

Для этой цели я использовал sgdisk, скопировав таблицу разделов с /dev/sdc на /dev/sdf. Убедитесь, что вы заменили имена устройств на свои собственные, если это необходимо.

Обратите внимание на порядок: сначала вы указываете диск, к которому подключается диск! Для меня это немного нелогично, но просто убедитесь, что вы всё сделали правильно, чтобы избежать ещё одного сбоя диска в массиве ;-)

sgdisk -R /dev/sdf /dev/sdc

Чтобы избежать конфликтов UUID, сгенерируйте новые UUID для нового диска:

sgdisk -G /dev/sdf

И вот, наконец, пришло время добавить новый диск в массив и начать процесс восстановления! (Ладно, это не совсем вечеринка, скорее это довольно медленный и нервирующий процесс, потому что вам действительно, очень не хочется, чтобы в это время вышел из строя еще один диск. Хотя пиво, возможно, поможет.)

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

mdadm -–manage /dev/md0 -–add /dev/sdf1

Если все пройдет гладко, диск будет добавлен в массив без проблем. Я думаю, что по умолчанию он добавляется как «горячий резерв», но поскольку в этом массиве отсутствует диск (тот, который вышел из строя), он немедленно запускается, и начинается процесс восстановления.

Вы можете следить за этим следующим образом:

watch cat /proc/mdstat

Вероятно, это займет некоторое время; на моем скромном сервере (в основном, основанном на потребительском оборудовании и настольных жестких дисках) скорость достигала чуть менее 100 МБ/с. Учтите, что это RAID-6, поэтому при восстановлении требуется много вычислений четности; RAID-10 был бы намного быстрее. В этой конкретной машине установлен четырехъядерный процессор AMD A10 9700E (буква «E» означает, что это энергоэффективная модель с пониженной тактовой частотой, то есть не сверхбыстрая), просто чтобы вы имели представление о том, чего ожидать. С девятью 8-терабайтными дисками в моей конфигурации полное восстановление заняло чуть более 24 часов.

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

После завершения добавьте изменения обратно в файл /etc/fstab, перезагрузите систему и наслаждайтесь своими файлами :-)

Поделиться на BlueskyПоделиться на FacebookПоделиться на LinkedInПоделиться на TumblrПоделиться на XПоделиться на LinkedInЗакрепить на Pinterest

Миккель Кристенсен

Об авторе

Миккель Кристенсен
Миккель - создатель и владелец сайта miklix.com. Он имеет более чем 20-летний опыт работы в качестве профессионального программиста/разработчика программного обеспечения и в настоящее время работает на полную ставку в крупной европейской IT-корпорации. Когда он не ведет блог, то тратит свое свободное время на огромное количество интересов, хобби и занятий, что в некоторой степени отражается в разнообразии тем, освещаемых на этом сайте.