Насколько я знаю, вы не можете сделать это с mdadm / программным RAID-массивом Linux, поскольку единственные поддерживаемые им форматы метаданных - Intel (R) Matrix Storage Manager и DDF .

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

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

Поддержка Fake RAID

Статьи по dmraid / Fake RAID из Документации сообщества Ubuntu и Arch Linux Wiki могут быть вам полезны.

Программный RAID Linux против поддельного RAID

Выдержка из Linux Raid Wiki на поддельном RAID :

Надлежащие аппаратные RAID-системы представлены в Linux как блочное устройство [...]

BIOS / прошивка RAID aka поддельные карты рейдов:

• [...]
• , если карта или материнская плата 'raid' Умирает, тогда вам часто приходится находить точную замену, и это может быть сложно для старых карт
• , если диски перемещаются на другие машины, данные не могут быть легко прочитаны
• , обычно нет мониторинга или создание отчетов о массиве - если возникает проблема, то она может не отображаться, пока машина не будет перезагружена и , кто-то фактически наблюдает за экраном загрузки BIOS (или пока не произойдет многократные ошибки и ваши данные не будут потеряны)
• вы доверяете свои данные непатентованному программному обеспечению, записанному в BIOS, которое, вероятно, не было протестировано, не имеет механизма поддержки и почти не имеет сообщества.
• [...]

Учитывая, что целью RAID обычно является снижение риска, справедливо будет сказать, что использование fakeraid - ужасная идея, и лучше сосредоточить энергию на любом истинном наборе HW или рейд SW в ядре [...]

У него была почти такая же проблема с контроллером «fake RAID» it8212 и парой дисков на RAID0. Удивительно, но mdadm мог решить проблему, хотя и с небольшим методом проб и ошибок. Если вы знаете / помните размер фрагмента (квант каждого параллельного диска для чтения / записи для каждого диска), вы можете попробовать что-то подобное ( пока не пробуйте ):

 sudo mdadm --build --verbose --run --chunk=64 /dev/md0 --level=raid0 --raid-devices=2 /dev/sde /dev/sdd

Если / dev / md0 уже занят, не стесняйтесь использовать инкрементные числа вместо 0. Конечно, / dev / sde и / dev / sdd где диски в моем случае, а 64k был моим размером, но вы можете легко определить свою собственную конфигурацию с помощью: sudo fdisk -l

Здесь перечислены все разделы всех ваших физических дисков. Те два, которые нас интересуют, должны быть абсолютно идентичны по размеру, цилиндрам, секторам и т. Д. Кроме того, поскольку порядок параметров определенно имеет значение, первый (вместо моего / dev / sde) должен иметь таблицу разделов (или часть этого, если вы использовали расширенные разделы DOS), а второй (мой / dev / sdd) будет выглядеть полностью испорченным. Будьте осторожны, чтобы не трогать другие не-рейдовые диски, однако :-) ОТАХ, если оба они кажутся недействительными, вы можете перестать читать этот ответ, он не будет работать для вас: - (

Использование --build ( вместо --create) преимущество заключается в том, что он пропускает создание информации о суперблоке, избегая риска стирания данных и, самое главное, запуская реальные данные из сектора 0, создавая, таким образом, «унаследованную» сборку, которая является самой «большой». «Поддельные рейды» сделали бы производители чипсетов. (обоснованное предположение: их информация о суперблоке записана в памяти чипсета NV, поэтому им не нужно записывать метаданные на диски).

Теперь, если вы не t помните, что требуется исходный размер чанка, проб и ошибок ... Попробуйте каждый раз создавать с чанком разного размера, затем явно используйте fdisk -l для / dev / md0 и посмотрите, правильно ли отображается информация о разделе. Если это так, попробуйте монтирование одного из обнаруженных разделов как доступного только для чтения и проверка некоторых данных (предпочтительно текстовых), чтобы убедиться. Если нет, отменить. Отменить сборку mdadm g и снова сделайте диск доступным, используйте sudo mdadm --stop /dev/md0 и sudo mdadm --remove /dev/md0, затем попробуйте снова, с другим размером чанка.

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

 /dev/sde1   *          63    47118644    23559291    7  HPFS/NTFS/exFAT
 /dev/sde2        47118645   102896324    27888840    7  HPFS/NTFS/exFAT
 /dev/sde4       102896325   980463014   438783345    5  Extended

Почти в каждом случае вы можете найти строки идентификаторов близко к началу каждого типа раздела. то есть. Сам NTFS, в случае NTFS. Используя dd, скопируйте первые несколько секторов диска (/ dev / md0) в файл.

 sudo dd if=/dev/md0 of=testfile bs=1024 count=256 skip=0

Это должно скопировать первые (skip = 0) 256K данных на диск в «testfile». Теперь, используя что-то вроде:

strings -a -t d testfile | grep NTFS

или x вместо d, если вы предпочитаете hex, или, проще говоря,

hexdump -C testfile | less

, тогда ищите с помощью '/'

, и вы можете найти положение строки во всем диске. Сравните это с вычисленным смещением раздела. Например, в моем случае первый раздел ntfs начался в 63-м секторе, что приводит к смещению 63 * 512 = 32256. Строка «NTFS» была найдена в месте 32259, поэтому мы считаем это «совпадением» (3 байты публикуют начало). (Не забудьте добавить skip * bs в ваш расчет, если в dd используется ненулевой пропуск). К сожалению, совпадение не обязательно означает, что это правильный размер куска, в то время как несоответствие будет означать, что это точно не так.