Хорошо, вот что я сделал. Пусть это поможет следующему человеку.
Установление фактов
Сначала я подключил все диски к HBA. GNU/Linux пытался собрать
рейд, но действительно нашел (как минимум) два рейдовых тома (и немного больше). я
затем сделал резервную копию первых 32 и последних 32 МБ каждого диска, проиндексированных
их WWID/WWN.
Затем я скачал спецификацию SNIA DDF.
(https://www.snia.org/tech_activities/standards/curr_standards/ddf)
потому что я знал, что megaraid/dell (частично) реализовал его (файл ddf
магия якорного блока не де11де11 случайно :), а потом написал очень
уродливый скрипт для декодирования данных и их осмысления.
Это показало мне, что массив фактически был разделен на три разных
конфигурации, одна из которых включала один диск, другая включала этот
диск и еще 4, и еще один, который содержал оставшиеся 2 диска.
Сам сценарий не очень полезен без понимания того, что вы делаете, поэтому я не включил его сюда.
В конце концов, это позволило мне получить правильный первоначальный порядок
диски. Подсказка: после создания массива запишите порядок WWN
(perccli /c0/s0 показать все | grep WWN) и размер полосы, по крайней мере.
Этот процесс также дал мне начальное смещение (всегда 0) и размер
разделов (19531825152 секторов).
Вариант raid5, используемый H740P (и, вероятно, все megaraid
контроллеры) называется левосимметричный или "RAID-5 с чередованием четности N с
Продолжение данных (PRL=05, RLQ=03)".
Сборка дисков для тестирования
Затем я попытался протестировать рейд, используя мдадм --сборка. К сожалению, mdadm отказывается собирать массивы raid5 - вы
имеют для записи в массив и уничтожения данных :(
В качестве обходного пути, чтобы проверить правильность порядка, я запустил kvm
в режиме моментального снимка с некоторым случайным загрузочным образом GNU/Linux, как /dev/sda и диски как виртуальные диски:
exec kvmb -моментальный снимок -m 16384 \
-диск файл=linux.img,снимок=выкл\
-drive file=/dev/sdm,if=virtio,snapshot=on\
-drive file=/dev/sdl,if=virtio,snapshot=on\
-drive file=/dev/sdk,if=virtio,snapshot=on\
-drive file=/dev/sdi,if=virtio,snapshot=on\
-drive file=/dev/sdg,if=virtio,snapshot=on\
-drive file=/dev/sdf,if=virtio,snapshot=on\
-drive file=/dev/sdh,if=virtio,snapshot=on
Это заставило диски отображаться в указанном порядке как /dev/vda, /dev/vdb и так далее, что позволило мне легко протестировать различные варианты. Первая попытка внутри виртуальной машины удалась:
mdadm --создать /dev/md0 -f \
--метаданные 1.0 \
--raid-устройства 7 \
-z $((19531825152/2))K -c 256K \
-l raid5 -p ddf-N-продолжить \
--assume-clean -k повторная синхронизация \
/dev/vd?
Для рейда5 размер раздела некритичен - если он больше, то ваш GPT
таблица разделов повреждена и у вас есть лишние данные, но остальная часть
диск должен оставаться читаемым.
Я проверил правильность данных, смонтировав раздел (который должен
не выдавать ошибок, но может добиться успеха, даже если порядок неправильный), и использование
btrfs скраб, который проверяет контрольные суммы метаданных и блоков данных, что является окончательным тестом и большим плюсом btrfs.
Затем я снова запустил backzp.
Затем я записал WWN всех дисков по порядку, чтобы воссоздать его.
с перкли. Я также сделал резервную копию первого и последнего 1 ГБ данных
сам том, на случай, если рейд-контроллер перезапишет их.
Перемещение тома обратно в рейд-контроллер
Поскольку около 14 ТБ данных не были скопированы (поскольку данные могут быть
достали из другого места с некоторым усилием, и я был слишком нетерпелив, чтобы
дождитесь копии), полное восстановление не было вариантом, который я с нетерпением ждал
чтобы, поэтому я попытался переместить массив обратно в контроллер.
Моя первая попытка состояла в том, чтобы отформатировать массив как контейнер DDF с помощью файла raid5.
объем внутри, используя те же параметры, что и контроллер, но, к сожалению, контроллер мегарайда - при использовании
Сам DDF - не поддерживает "чужой" DDF для импорта и показывал диски просто
как «ненастроенный товар».
Затем я попытался воссоздать массив, просто добавив его снова, например:
perccli /c0 add vd r5 name=XXX дисков=3,6,9,1,2,3,0 pdcache=off wb ra strip=256
Выполнение этого на загруженной системе с perccli гарантирует, что контроллер рейда
будет выполнять фоновую инициализацию, которая не является деструктивной и, с RAID5,
даже не уничтожит данные, если порядок диска или размер полосы неправильный, так как
пока вы используете точно все диски из исходного массива в любом порядке, не пропуская ни одного и не давая слишком много.
Вот тут у меня не получилось - как-то совсем напортачил порядок дисков,
а также удалось повредить первые 1,5 МБ тома. у меня абсолютно
понятия не имею, что пошло не так, но я пробовал много перестановок и не видел
правильные данные, до такой степени, что я думал, что рейд-контроллер
каким-то образом переупорядочить мои диски (но это не так, он точно принимает порядок, как
указан).
Короче говоря, я снова подключил диски к HBA и попытался
не удалось понять это. Вот где мне пригодилась моя оригинальная резервная копия:
хотя я потерял порядок дисков, я зорко посмотрел на резервную копию, и
понизил потенциальный порядок до двух возможных перестановок, просто глядя на шестнадцатеричные дампы. Создание массива с мдадм и проверка данных у меня правильный порядок.
Я потом еще раз записал порядок WWN, прикрепил диски к
контроллер, загрузился и сделал perccli /c0 добавить.... Затем я восстановил первый
1,5 МБ тома (включая раздел GPT и метки LVM, а также
некоторые старые оставшиеся данные о мусоре, которые были очень полезны во время угадывания, что
порядок может быть). Определенный уровень уверенности в возможности отменить
ошибки помогают в этой ситуации.
Результат: массив вернулся, btrfs непротиворечива, а контроллер теперь инициализируется в фоновом режиме, что замедляет работу всей системы на несколько дней, но это небольшая цена.
Вещи узнали
Я многому научился!
Контроллеры perc (и, вероятно, все контроллеры megaraid) не справляются
хорошо с частыми быстрыми и прерывистыми проблемами с дисками - я подозреваю, что диски уходят и быстро возвращаются, вызывая состояние гонки, когда контроллер пытался записать новую конфигурацию на диски и лишь частично преуспел с некоторыми дисками, в конечном итоге разделив рейд на два . Это явно глюк прошивки. Но тогда кто мог ожидать, что силовые кабели будут неисправны...
mdadm не очень полезен для понимания или отображения заголовков DDF.
Я просто не мог разобраться в отображаемых данных, и, как я выяснил,
при расшифровке заголовков самостоятельно, это потому, что много информации
отсутствует в --деталь и --исследовать вывод.Это также не очень полезно для экспериментов, так как отказывается выполнять неразрушающую сборку только для чтения.
контроллеры perc/megaraid используют внутренний формат SNIA DDF, и это
общедоступная спецификация, оказалась крайне полезной, хотя в итоге я и без этой информации разобрался, что мне нужно.
Возможность угадать правильный порядок полос рейда только по данным
очень полезно. Остатки мусора и другие данные, которые могут в этом помочь
тоже очень полезно. Я рассмотрю возможность записи «диск 1», «диск 2» и так далее в
«пустые» области заголовков тома RAID с этого момента (в первых 2 МБ есть длинные участки по 0 байт).
Облажаться очень легко - имена устройств, номера членов рейда, WWN,
номера слотов и т. д., если они разные, могут означать много данных для
управлять, а WWN длинные, и мои старые глаза уже не так хороши. К тому же, я не организован и излишне самоуверен :/
Создание и удаление массива с использованием дисков с данными на нем
не сотрет данные, по крайней мере, с RAID5 и с использованием фонового режима
инициализация. Инициализация переднего плана почти наверняка обнулится
диски. Это означает, что вы можете создавать и удалять массив сколько угодно раз.
раз, как вы хотите, без риска потери данных, за одним возможным исключением:
для удаления массива иногда требуется принудительная опция, потому что RAID
контроллер считает, что он «используется» из-за действительной метки раздела. И это мощь обнулите метку GPT - YMMV и убедитесь, что у вас есть резервная копия
первые несколько мегабайт на всякий случай.
Perc/megaraid не понимают DDF-контейнеры, отличные от Dell/megaraid. В
по крайней мере, я не узнал, как заставить мой контроллер принимать DDF, созданный mdadm
контейнеры. Возможность отформатировать диск в GNU/Linux и переместить его обратно в контроллер очень помогла бы мне и избежала многих часов горя с моей стороны.
Резюме
Вернул все без восстановления из бэкапа, за счет
несколько дней медленной фоновой инициализации.я записал свое решение
выше, в случае, если некоторые из них могут быть полезны другим людям в
подобные ситуации.
