LINUX.ORG.RU
ФорумTalks

Crash raid1 mdadm after reset

 ,


0

2

Несколько дней назад на домашнем сервере настраивал корректное выключение системы (см. ссылку) Приходилось многократно нажимать ресет для ускорения процесса тестирования изменений. В итоге, после одного из ресетов система перестала загружаться. Собственно, корень был представлен в виде mdadm raid1 из двух устройств /dev/sda1 /dev/sdb1. Выяснилось, что оба диска по команде

mdadm --examine /dev/sdX
выдали
mdadm: No md superblock detected on /dev/sdX
Гуглёж показал, что надежды спасти рейд нет. Сказать, что я опечалился, ничего не сказать... Но каким-то чудом (знаний не хватает объяснить) то ли сразу, то ли после fsck /dev/sda1 примонтировался одиночный раздел /dev/sda1.

Восстановив загрузчик, отказавшись от рейда вернул систему в рабочее состояние. От рейда отказался т.к., smart -a /dev/sdb уже более года назад сообщал о FILED STATE. Собственно, для себя и объяснил произошедшее тем, что один из жёстких дисков умер, рейд развалился (возможно синхронизировался) и на этом фоне я нажал ресет, что привело к фатальным последствиям в виде «No md superblock detected».

На будущее создал raid1 с одним отсутствующим диском. Так вот, сегодня заметил дикие тормоза при заходе по ssh на сервер из домашней сети, пытался определить причину. Подозрения появились, но не на 100%, для надёжности решил перезагрузить сервер. Результата выполнения команды reboot или загрузки системы не дождался, решил нажать reset для однозначности перезагрузки. В итоге, следующий зеркальный рейд из двух дисков со всеми документами на почти 2TB выдаёт

mdadm: No md superblock detected on /dev/sdX
Никакое монтирование отдельных дисков, ни fsck файловую систему восстановить не помогло (предполагаю, что дело в различии метаданных, в первом случае были v 0.90 для обеспечения загрузки, во втором v 1.2).

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

P.S. Сейчас восстанавливаю данные из бекапа, какое счастье, что он есть... Надеюсь, что всё пройдёт гладко, хоть duplicity на Athlon 3200+ шевелится, ну, очень медленно.

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

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

King_Carlo ★★★★★ ()
Ответ на: комментарий от King_Carlo

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

Jurik_Phys ★★★★★ ()

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

[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 - нет. Рейд развалился. Вместо того, чтобы его чинить, ты методом многочисленного тыка куда попало взял и грохнул остатки

router ★★★★★ ()

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

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

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

DawnCaster ()
Ответ на: комментарий от router

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

sda1
sdX

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

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

Jurik_Phys ★★★★★ ()
Ответ на: комментарий от DawnCaster

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

Jurik_Phys ★★★★★ ()
Ответ на: комментарий от Jurik_Phys

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

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

Camel ★★★★★ ()
Ответ на: Ответ на ответ от Camel

Согласен, что возможно, не все варианты испробовал, но больше вариантов не вижу. По ссылке восстановили 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»

Jurik_Phys ★★★★★ ()
Ответ на: комментарий от Jurik_Phys

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

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

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

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

aidaho ★★★★★ ()
Ответ на: комментарий от aidaho

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

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

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

router ★★★★★ ()
Ответ на: комментарий от aidaho

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

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

Jurik_Phys ★★★★★ ()
Ответ на: комментарий от router

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

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

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

Jurik_Phys ★★★★★ ()

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

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

h578b1bde ★☆ ()
Последнее исправление: h578b1bde (всего исправлений: 1)
Ответ на: комментарий от h578b1bde

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

mandala ★★★★ ()
Ответ на: комментарий от h578b1bde

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

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

Jurik_Phys ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.