корень был представлен в виде mdadm raid1 из двух устройств /dev/sda1 /dev/sdb1

grub на обоих дисках был или на одном? Могло получиться так, что загрузчик был на диске который умер.

На обоих дисках, причём при настройке тестировал загрузку с обоих дисков. Но вопрос не в этом, рейд в любом случае умер так, что его даже rescuecd распознать не смогло.

Приходилось многократно нажимать ресет для ускорения процесса тестирования изменений

[censored]

был представлен в виде mdadm raid1 из двух устройств /dev/sda1 /dev/sdb1
mdadm --examine /dev/sdX

sda1
sdX

Ну ты понял, да?

Подозрения появились, но не на 100%, для надёжности решил перезагрузить сервер. Результата выполнения команды reboot или загрузки системы не дождался, решил нажать reset для однозначности перезагрузки

facepalm

Никакое монтирование отдельных дисков, ни fsck файловую систему восстановить не помогло (предполагаю, что дело в различии метаданных, в первом случае были v 0.90 для обеспечения загрузки, во втором v 1.2).

Предполагаю, дело в том, что ты даже примерно не представляешь, что делаешь. Сначала диагностика, потом какие-либо изменения.

Для вас, особо одарённых, у mdadm есть вариант "--examine --scan". А вообще-то в спорных ситуациях можно использовать blkid и blkid | grep

Собственно, вопрос. На сколько нормально поведение mdadm, когда от ресета рейд умирает, да, так, что его уже не восстановить?

Защита от дурака бывает, от дурака с правами root - нет. Рейд развалился. Вместо того, чтобы его чинить, ты методом многочисленного тыка куда попало взял и грохнул остатки

Приходилось многократно нажимать ресет для ускорения процесса тестирования изменений.

Не стоило так делать. На худой конец есть волшебные комбинации sysrq: sysrq+s, sysrq+u, sysrq+b. В такой последовательности они флюшнут все изменения на HDD, перемонтируют ФС в read-only, и выполнят перезагрузку.

На будущее, если будете когда-нибудь ещё раз делать рейд - не забывайте бэкапить суперблоки, или хотя-бы его параметры, такие как data-offset. Можно будет в случае затирания суперблока зная оффсет для данных вручную сделать виртуальное устройство с одного из зеркал через device mapper (гуглите доки по dmsetup), и примонтировать его как обычно без всяких плясок с бубном.

особо одарённых, у mdadm есть вариант "--examine --scan".

sda1
sdX

Ну ты понял, да?

Я понял, что по сути сказать нечего, но есть острое желание сказать своё фи. Твоё право, на то и толксы.

Вот за это направление спасибо, надо будет разобраться.

Ответ на ответ

Вам всё правильно сказали, а вы уцепились за одну всего лишь претензию.

флюшнут

Флашнут :-)

Согласен, что возможно, не все варианты испробовал, но больше вариантов не вижу. По ссылке восстановили raid 5, но там superblock пропал только на одном диске, возможно ли восстановить raid1, когда проблема сразу на двух дисках - вопрос открытый.

If there is no superblock on that either, you can just assemble your array and leave /dev/sdb1 out. This will assemble it degraded. Then you can add your /dev/sdb1 and let it resync. Here are the steps I would follow.

mdadm --zero-superblock /dev/sdb
mdadm --zero-superblock /dev/sdb1
mdadm --assemble /dev/md0 /dev/sd[cde]1
mdadm --add /dev/md0 /dev/sdb1

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

P.S. при наличии актуального бекапа можно позволить халатно отнестись к процессу восстановления самого рейда.

P.P.S. склоняюсь к тому, что проблема в железе: smart /dev/sde тыц, /dev/sdf тыц, а именно в перегреве, максимальная температура у обоих дисков 54 градуса, а у /dev/sde есть ещё и «ATA Error Count: 4»

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

Звучит как пассивно-агрессивное перекладывание ответственности с больной головы на здоровую.

Причина отказа очевидна, и озвучена в самом верху:

многократно нажимать ресет

Причина отказа очевидна, и озвучена в самом верху:

Причина отказа в том, что ТС перепутал sda и sda1, а потом впал в истерику

Метаданные от ресета не умирают

Причина отказа очевидна, и озвучена в самом верху:

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

ТС перепутал sda и sda1

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

С другой стороны хороший урок, который не стоил дорого благодаря duplicty и ежедневным бекапам.

Приходилось многократно нажимать ресет для ускорения процесса тестирования изменений
уже более года назад сообщал о FILED STATE
на этом фоне я нажал ресет
решил нажать reset для однозначности перезагрузки

Нынче на ЛОРе пять звёзд лишь чемпионам спецолимпиад дают?

С каких это пор звезды стали мерилом технической грамотности?

Не ошибается тот, кто ничего не делает.

Как бы то ни было, опыт получен, выводы сделаны.