Массив Mdadm неактивен, как исправить?

Содержание

Вопрос или проблема
Ответ или решение
Теория
Пример
Применение

Вопрос или проблема

У меня массив RAID5, настроенный с помощью MDADM в Ubuntu 24.04 LTS. Массив состоит из пяти дисков по 8 ТБ, и в последнее время в нем не было изменений.

Сегодня я заметил, что массив недоступен.

mdadm --detail /dev/md0 показывает, что массив неактивен:

$ mdadm --detail /dev/md0
/dev/md0:
           Version : 1.2
        Raid Level : raid5
     Total Devices : 5
       Persistence : Superblock is persistent
             State : inactive
   Working Devices : 5

              Name : Europa:0  (local to host Europa)
              UUID : 62595935:e04505fc:3e79426a:40326185
            Events : 76498

    Number   Major   Minor   RaidDevice

       -       8        1        -        /dev/sda1
       -       8       81        -        /dev/sdf1
       -       8       65        -        /dev/sde1
       -       8       49        -        /dev/sdd1
       -       8       33        -        /dev/sdc1

Используя mdadm --examine для каждого диска, я обнаружил, что все они показывают состояние Clean, и 4 из них показывают состояние массива AAAAA (все диски активны), но один из них (sda1) показывает состояние массива ....A

Используя cat /proc/mdstat, я обнаружил, что отображается ТОЛЬКО устройство sda1!

$ sudo cat /proc/mdstat
Personalities : [raid1] [raid0] [raid6] [raid5] [raid4] [raid10] 
md1 : active raid1 sdg1[1] sdh1[0]
      2930132992 blocks super 1.2 [2/2] [UU]
      bitmap: 0/22 pages [0KB], 65536KB chunk

md0 : inactive sda1[4]
      7813893632 blocks super 1.2

Посмотрев mdadm --examine на количество событий и время обновления, я увидел, что sda1 имеет немного больше событий и более недавнее время обновления, чем остальные диски:

$ mdadm --examine /dev/sda1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 | egrep 'Event|/dev/sd'
/dev/sda1:
         Events : 76498
/dev/sdc1:
         Events : 76490
/dev/sdd1:
         Events : 76490
/dev/sde1:
         Events : 76490
/dev/sdf1:
         Events : 76490

$ mdadm --examine /dev/sda1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 | egrep 'Update Time|/dev/sd'
/dev/sda1:
    Update Time : Mon Jan 13 14:51:59 2025
/dev/sdc1:
    Update Time : Mon Jan 13 05:03:20 2025
/dev/sdd1:
    Update Time : Mon Jan 13 05:03:20 2025
/dev/sde1:
    Update Time : Mon Jan 13 05:03:20 2025
/dev/sdf1:
    Update Time : Mon Jan 13 05:03:20 2025

Итак, как это интерпретировать?

При поиске в интернете я нашел, что большинство людей сообщает обратное: у одного диска меньше событий, чем у других, и у одного диска более раннее время обновления, чем у других. Я не могу представить, что 4 диска испортились одновременно, особенно поскольку не было отключения питания или чего-то еще, что могло бы объяснить широкомасштабную проблему с оборудованием.

Итак, что это значит и как восстановить массив?

Ответ или решение

Ваша проблема с неактивным массивом RAID5 на Ubuntu 24.04 LTS может быть решена, но требует внимательного подхода. Во-первых, важно понимать основы работы RAID5 и mdadm, чтобы лучше интерпретировать симптомы и принять осознанные решения.

Теория

RAID5 использует распределение данных и избыточности (паритет) для защиты от отказа одного из дисков без потери данных. В вашем случае массив состоит из пяти 8TB дисков. Основываясь на описании проблемы, состояние массивов стало "неактивным", что, по сути, означает, что операционная система не может собрать ваш RAID-массив в функционирующую единицу.

Одним из индикаторов является значительное различие в числе событий (Event Count) и времени последнего обновления (Update Time) у дисков. Обычно в RAID5 диски должны иметь одинаковые параметрические значения. В вашем случае мы видим, что на диске /dev/sda1 число событий больше и время обновления более свежее, чем на других дисках. Это может свидетельствовать о том, что данный диск вышел из состава массива позже других, или же сконфигурирован по-другому, что привело к его частичной изоляции.

Пример

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

Применение

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

Создайте резервную копию данных: Прежде чем предпринимать какие-либо действия по восстановлению, крайне важно создать резервные копии любых доступных данных, если это возможно. В случае неудачи это обеспечит возможность восстановления информации другими способами.
Проверьте физические соединения: Убедитесь, что все кабели и соединения на аппаратном уровне в порядке. Отключение и повторное подключение SATA или питания может иногда решать проблемы.
Отключите и повторно соберите массив:
- Выполните команду mdadm --stop /dev/md0 для остановки массива.
- Затем попытайтесь снова собрать массив с использованием mdadm --assemble --force /dev/md0 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1.
Проанализируйте детали сборки: Если вы видите сообщение о том, что массив собран успешно, но все еще "неактивен", следует повторно проанализировать логи ошибок. Используйте dmesg или проверяйте /var/log/syslog.
Проверьте диск /dev/sda1:
- Поскольку этот диск имеет наибольшее количество событий, он может содержать критическую информацию. Размисите диск временно и выполните его проверку для поиска ошибок. Возможно, вам придется восстановить supersblock или другой сервисный сектор.
- Используйте команду mdadm --examine --scan для понимания текущей конфигурации RAID и правильности идентификации.
Принудительное восстановление дисков: В некоторых случаях можно попытаться участвовать в реконфигурации массива с помощью mdadm --create --assume-clean, который позволит произвести сборку массива с учетом сохраненного паритета. Однако используйте с осторожностью, чтобы избежать перезаписи данных.
Последующее тестирование и мониторинг: Если сборка удалась, убедитесь, что система работает корректно. Проверьте доступность всех разделов и попробуйте смонтировать массив для проверки содержимого.

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