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

У меня на жестком диске 3 1 ТБ на Ubuntu 11.04 настроен как программный рейд 5. Данные еженедельно копировались на другой отдельный жесткий диск компьютера, пока тот полностью не вышел из строя и не был удален. Несколько дней назад у нас было отключение электричества, и после перезагрузки моя коробка не смонтировала рейд. В моей бесконечной мудрости я вошел

mdadm --create -f...

команда вместо

mdadm --assemble

и не заметил пародии, которую я совершил, до и после. Он начал разрушать массив и приступил к его сборке и синхронизации, что заняло ~ 10 часов. После того, как я вернулся, я увидел, что массив успешно запущен и работает, но рейд не

Я имею в виду отдельные диски разделены (тип раздела f8), но md0устройство нет. С ужасом осознавая, что я сделал, я пытаюсь найти какие-то решения. Я просто молюсь, чтобы --createне переписать все содержимое жесткого драйвера.

Может кто-нибудь ПОЖАЛУЙСТА, помогите мне с этим - данные на диске очень важны и уникальны ~ 10 лет фотографий, документов и т. Д.

Возможно ли, что, указав участвующие жесткие диски в неправильном порядке, можно mdadmперезаписать их? когда я делаю

mdadm --examine --scan 

Я получаю что-то вроде ARRAY /dev/md/0 metadata=1.2 UUID=f1b4084a:720b5712:6d03b9e9:43afe51b name=<hostname>:0

Достаточно интересно, что раньше имя было «рейд», а не «хозяин» с добавленным: 0.

Вот «очищенные» записи конфигурации:

DEVICE /dev/sdf1 /dev/sde1 /dev/sdd1

CREATE owner=root group=disk mode=0660 auto=yes

HOMEHOST <system>

MAILADDR root


ARRAY /dev/md0 metadata=1.2 name=tanserv:0 UUID=f1b4084a:720b5712:6d03b9e9:43afe51b


Here is the output from mdstat

cat /proc/mdstat 
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md0 : active raid5 sdd1[0] sdf1[3] sde1[1]
1953517568 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>


fdisk shows the following:

fdisk -l

Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000bf62e

Device Boot Start End Blocks Id System
/dev/sda1 * 1 9443 75846656 83 Linux
/dev/sda2 9443 9730 2301953 5 Extended
/dev/sda5 9443 9730 2301952 82 Linux swap / Solaris

Disk /dev/sdb: 750.2 GB, 750156374016 bytes
255 heads, 63 sectors/track, 91201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000de8dd

Device Boot Start End Blocks Id System
/dev/sdb1 1 91201 732572001 8e Linux LVM

Disk /dev/sdc: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00056a17

Device Boot Start End Blocks Id System
/dev/sdc1 1 60801 488384001 8e Linux LVM

Disk /dev/sdd: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000ca948

Device Boot Start End Blocks Id System
/dev/sdd1 1 121601 976760001 fd Linux raid autodetect

Disk /dev/dm-0: 1250.3 GB, 1250254913536 bytes
255 heads, 63 sectors/track, 152001 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/dm-0 doesn't contain a valid partition table

Disk /dev/sde: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x93a66687

Device Boot Start End Blocks Id System
/dev/sde1 1 121601 976760001 fd Linux raid autodetect

Disk /dev/sdf: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xe6edc059

Device Boot Start End Blocks Id System
/dev/sdf1 1 121601 976760001 fd Linux raid autodetect

Disk /dev/md0: 2000.4 GB, 2000401989632 bytes
2 heads, 4 sectors/track, 488379392 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 524288 bytes / 1048576 bytes
Disk identifier: 0x00000000

Disk /dev/md0 doesn't contain a valid partition table

В соответствии с предложениями я очистил суперблоки и заново создал массив с --assume-cleanопцией, но безуспешно.

Есть ли инструмент, который поможет мне восстановить хотя бы некоторые данные? Может кто-нибудь сказать мне, что и как делает mdadm --create при синхронизации, чтобы уничтожить данные, чтобы я мог написать инструмент для отмены того, что было сделано?

После повторного создания рейда я запускаю fsck.ext4 / dev / md0 и вот результат

root @ tanserv: / etc / mdadm # fsck.ext4 / dev / md0 e2fsck 1.41.14 (22 декабря 2010 г.) fsck.ext4: неверный суперблок, пробуются резервные блоки ... fsck.ext4: неверное магическое число в супер- блокировать при попытке открыть / dev / md0

Суперблок не может быть прочитан или не описывает правильную файловую систему ext2. Если устройство действительно и оно действительно содержит файловую систему ext2 (а не swap или ufs или что-то еще), то суперблок поврежден, и вы можете попробовать запустить e2fsck с альтернативным суперблоком: e2fsck -b 8193

По предложению Шейна я попробовал

root@tanserv:/home/mushegh# mkfs.ext4 -n /dev/md0
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=128 blocks, Stripe width=256 blocks
122101760 inodes, 488379392 blocks
24418969 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
14905 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
    102400000, 214990848

и запустите fsck.ext4 с каждым резервным блоком, но все вернули следующее:

root@tanserv:/home/mushegh# fsck.ext4 -b 214990848 /dev/md0
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Invalid argument while trying to open /dev/md0

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

Какие-либо предложения?

С уважением!

Хорошо, что-то беспокоило меня по поводу вашей проблемы, поэтому я запустил виртуальную машину, чтобы погрузиться в поведение, которое следует ожидать. Я доберусь до того, что беспокоило меня через минуту; Сначала позвольте мне сказать это:

Сделайте резервную копию этих дисков, прежде чем пытаться что-либо !!

Возможно, вы уже нанесли ущерб сверх того, что сделал ресинк; Можете ли вы уточнить, что вы имели в виду, когда сказали:

В соответствии с предложениями я очистил суперблоки и заново создал массив с опцией --assume-clean, но безуспешно.

Если ты пробежал mdadm --misc --zero-superblock, то у тебя все будет хорошо.

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

dd if=/dev/sdd of=/path/to/store/sdd.img

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

Сценарий лучшего случая

Я собрал виртуальную машину, чтобы воссоздать ваш сценарий. Диски занимают всего 100 МБ, поэтому я не буду ждать вечно при каждой повторной синхронизации, но в противном случае это должно быть довольно точное представление.

Построил массив как можно более универсально и по умолчанию - 512 тыс. Блоков, левосимметричное расположение, диски в алфавитном порядке ... ничего особенного.

root@test:~# mdadm --create /dev/md0 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid5 sdd1[3] sdc1[1] sdb1[0]
      203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>

Все идет нормально; давайте создадим файловую систему и поместим в нее некоторые данные.

root@test:~# mkfs.ext4 /dev/md0
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=512 blocks, Stripe width=1024 blocks
51000 inodes, 203776 blocks
10188 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67371008
25 block groups
8192 blocks per group, 8192 fragments per group
2040 inodes per group
Superblock backups stored on blocks:
        8193, 24577, 40961, 57345, 73729

Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 30 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
root@test:~# mkdir /mnt/raid5
root@test:~# mount /dev/md0 /mnt/raid5
root@test:~# echo "data" > /mnt/raid5/datafile
root@test:~# dd if=/dev/urandom of=/mnt/raid5/randomdata count=10000
10000+0 records in
10000+0 records out
5120000 bytes (5.1 MB) copied, 0.706526 s, 7.2 MB/s
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

Хорошо. У нас есть файловая система и некоторые данные («данные» datafileи 5 МБ случайных данных с этим хешем SHA1 randomdata); давайте посмотрим, что произойдет, когда мы сделаем воссоздание.

root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md0
mdadm: stopped /dev/md0
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
unused devices: <none>
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 21:07:06 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 21:07:06 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 21:07:06 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdd1[2] sdc1[1] sdb1[0]
      203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>

Ресинхронизация очень быстро закончилась с этими крошечными дисками, но это произошло. Итак, вот что беспокоило меня раньше; ваш fdisk -lвывод. Отсутствие таблицы разделов на mdустройстве вовсе не является проблемой, как ожидается. Ваша файловая система находится непосредственно на поддельном блочном устройстве без таблицы разделов.

root@test:~# fdisk -l
...
Disk /dev/md1: 208 MB, 208666624 bytes
2 heads, 4 sectors/track, 50944 cylinders, total 407552 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 524288 bytes / 1048576 bytes
Disk identifier: 0x00000000

Disk /dev/md1 doesn't contain a valid partition table

Да, нет таблицы разделов. Но...

root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks

Совершенно допустимая файловая система, после повторной синхронизации. Так что это хорошо; давайте проверим наши файлы данных:

root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

Твердый - нет повреждения данных на всех! Но это с точно такими же настройками, поэтому ничто не было сопоставлено по-разному между двумя группами RAID. Давайте бросим эту штуку, прежде чем попытаемся ее сломать.

root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1

Делая шаг назад

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

Операция XOR для вычисления четности выглядит следующим образом:

DISK1  DISK2  DISK3  DISK4  PARITY
1      0      1      1    = 1
0      0      1      1    = 0
1      1      1      1    = 0

Итак, паритет распределяется по дискам.

DISK1  DISK2  DISK3  DISK4  DISK5
DATA   DATA   DATA   DATA   PARITY
PARITY DATA   DATA   DATA   DATA
DATA   PARITY DATA   DATA   DATA

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

Итак, все данные на «новом» диске стираются и восстанавливаются; либо создание свежих блоков данных из блоков четности для того, что должно было быть там, либо создание новых блоков четности.

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

DISK1  DISK2  DISK3  DISK4  DISK5
PARITY DATA   DATA   DATA   DATA
DATA   PARITY DATA   DATA   DATA
DATA   DATA   PARITY DATA   DATA

... это может быть просто восстановление DISK5из макета выше.

Таким образом, данные могут оставаться согласованными, даже если массив построен неправильно.

Бросать обезьяну в творчестве

(не гаечный ключ; вся обезьяна)

Тест 1:

Давайте сделаем массив в неправильном порядке! sdcтогда sdd, тогда sdb..

root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdc1 /dev/sdd1 /dev/sdb1
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:06:34 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:06:34 2012
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:06:34 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdb1[3] sdd1[1] sdc1[0]
      203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>

Хорошо, это все хорошо. Есть ли у нас файловая система?

root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/md1

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

Нет! Почему это? Потому что, хотя все данные там, они в неправильном порядке; то, что когда-то составляло 512 КБ A, затем 512 КБ B, A, B и т. д., теперь было перетасовано в B, A, B, A. Диск теперь выглядит как бред для проверки файловой системы, он не будет работать. Вывод mdadm --misc -D /dev/md1дает нам больше деталей; Это выглядит так:

Number   Major   Minor   RaidDevice State
   0       8       33        0      active sync   /dev/sdc1
   1       8       49        1      active sync   /dev/sdd1
   3       8       17        2      active sync   /dev/sdb1

Когда это должно выглядеть так:

Number   Major   Minor   RaidDevice State
   0       8       17        0      active sync   /dev/sdb1
   1       8       33        1      active sync   /dev/sdc1
   3       8       49        2      active sync   /dev/sdd1

Итак, это все хорошо. На этот раз мы перезаписали целую кучу блоков данных новыми блоками четности. Пересоздать, с правильным заказом сейчас:

root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:11:08 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:11:08 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:11:08 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks

Опрятно, там все еще есть файловая система! Все еще есть данные?

root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

Успех!

Тест 2

Ладно, давайте изменим размер чанка и посмотрим, не получится ли это у нас.

root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=64 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:21:19 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:21:19 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:21:19 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/md1

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

Да, да, это шланг, когда настроен так. Но мы можем выздороветь?

root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:21:51 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:21:51 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:21:51 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

Снова успех!

Тест 3

Это тот, который, я думал, убьет данные наверняка - давайте сделаем другой алгоритм компоновки!

root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --layout=right-asymmetric --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:32:34 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:32:34 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:32:34 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdd1[3] sdc1[1] sdb1[0]
      203776 blocks super 1.2 level 5, 512k chunk, algorithm 1 [3/3] [UUU]

unused devices: <none>
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
Superblock has an invalid journal (inode 8).

Страшно и плохо - думает, что нашел что-то и хочет исправить! Ctrl+ C!

Clear<y>? cancelled!

fsck.ext4: Illegal inode number while checking ext3 journal for /dev/md1

Хорошо, кризис предотвращен. Давайте посмотрим, остались ли данные нетронутыми после повторной синхронизации с неправильным макетом:

root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:33:02 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:33:02 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
    level=raid5 devices=3 ctime=Sat Jan  7 23:33:02 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

Успех!

Тест 4

Давайте также докажем, что обнуление суперблока не очень быстро:

root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --misc --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

Да, ничего страшного.

Тест 5

Давайте просто бросим все, что у нас есть на это. Все 4 предыдущих теста, вместе взятые.

• Неправильный порядок устройства
• Неправильный размер куска
• Неправильный алгоритм компоновки
• Обнуленные суперблоки (мы сделаем это между обоими творениями)

Вперед!

root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --misc --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1
root@test:~# mdadm --create /dev/md1 --chunk=64 --level=5 --raid-devices=3 --layout=right-symmetric /dev/sdc1 /dev/sdd1 /dev/sdb1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdb1[3] sdd1[1] sdc1[0]
      204672 blocks super 1.2 level 5, 64k chunk, algorithm 3 [3/3] [UUU]

unused devices: <none>
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/md1

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1

Вердикт?

root@test:~# mdadm --misc --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdd1[3] sdc1[1] sdb1[0]
      203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>

root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 13/51000 files, 17085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064  /mnt/raid5/randomdata

Вау.

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

Итак ... Как я могу получить свои данные ??

Любая информация о старой системе будет чрезвычайно полезна для вас. Если вы знаете тип файловой системы, если у вас есть какие-либо старые копии /proc/mdstatс информацией о порядке дисков, алгоритме, размере чанка и версии метаданных. У вас настроены почтовые оповещения mdadm? Если так, найдите старый; если нет, проверьте /var/spool/mail/root. Проверьте ваш, ~/.bash_historyчтобы увидеть, если ваша оригинальная сборка там.

Итак, список вещей, которые вы должны сделать:

1. Сделайте резервную копию дисков, ddпрежде чем делать что-нибудь !!
2. Попробуйте fsckтекущий активный md - возможно, вы только что построили в том же порядке, что и раньше. Если вы знаете тип файловой системы, это полезно; использовать этот конкретный fsckинструмент. Если какой-либо из инструментов предлагает что-то исправить, не позволяйте им, если вы не уверены, что они действительно нашли действительную файловую систему! Если кто-то fsckпредлагает что-то исправить для вас, не стесняйтесь оставить комментарий, чтобы спросить, действительно ли это помогает или просто собирает данные.
3. Попробуйте построить массив с другими параметрами. Если у вас есть старый /proc/mdstat, то вы можете просто подражать тому, что он показывает; если нет, то вы как бы в неведении - пробовать все разные порядки дисков разумно, но проверка каждого возможного размера чанка с каждым возможным порядком бесполезна. Для каждого, fsckчтобы увидеть, если вы получаете что-то многообещающее.

Так вот и все. Извините за роман, не стесняйтесь оставлять комментарии, если у вас есть какие-либо вопросы, и удачи!

сноска: до 22 тысяч знаков; 8к + стесняется ограничения по длине

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

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

У меня была похожая проблема:
после сбоя в программном массиве RAID5 я запустил mdadm --createего --assume-clean, но не смог его смонтировать. После двух недель копания я наконец восстановил все данные. Я надеюсь, что приведенная ниже процедура сэкономит кому-то время.

Короче говоря

Проблема была вызвана тем, что mdadm --createсделали новый массив, который отличался от оригинала в двух аспектах:

• другой порядок перегородок
• другое смещение данных RAID

Как было показано в блестящем ответе Шейна Мэддена , mdadm --createв большинстве случаев данные не уничтожаются! После определения порядка разбиения и смещения данных я смог восстановить массив и извлечь из него все данные.

Предпосылки

У меня не было резервных копий суперблоков RAID, поэтому я знал только то, что это был массив RAID5 на 8 разделах, созданный во время установки Xubuntu 12.04.0. У него была файловая система ext4. Еще одним важным знанием была копия файла, который также был сохранен в массиве RAID.

инструменты

Xubuntu 12.04.1 live CD использовался, чтобы сделать всю работу. В зависимости от вашей ситуации вам могут потребоваться некоторые из следующих инструментов:

версия mdadm, позволяющая указать смещение данных

sudo apt-get install binutils-dev git
git clone -b data_offset git://neil.brown.name/mdadm
cd mdadm
make

bgrep - поиск двоичных данных

curl -L 'https://github.com/tmbinc/bgrep/raw/master/bgrep.c' | gcc -O2 -x c -o bgrep -

hexdump, e2fsck, mount и шестнадцатеричный калькулятор - стандартные инструменты из репозиториев

Начните с полной резервной копии

Имена файлов устройств, например, /dev/sda2 /dev/sdb2и т. Д., Не являются постоянными, поэтому лучше записать серийные номера ваших дисков, заданные

sudo hdparm -I /dev/sda

Затем подключите внешний жесткий диск и создайте резервную копию каждого раздела вашего RAID-массива следующим образом:

sudo dd if=/dev/sda2 bs=4M | gzip > serial-number.gz

Определить оригинальное расположение RAID5

Различные макеты описаны здесь: http://www.accs.com/p_and_p/RAID/LinuxRAID.html
Чтобы узнать, как полосы данных были организованы в исходном массиве, вам нужна копия файла случайного вида, который, как вы знаете, был хранится в массиве. Размер порции по умолчанию, используемый в настоящее время, mdadmсоставляет 512 КБ. Для массива из N разделов вам нужен файл размером не менее (N + 1) * 512 КБ. JPEG или видео хорошо, поскольку они обеспечивают относительно уникальные подстроки двоичных данных. Предположим, наш файл называется picture.jpg. Мы читаем 32 байта данных в позициях N + 1, начиная с 100 КБ и увеличивая на 512 КБ:

hexdump -n32 -s100k -v -e '/1 "%02X"' picture.jpg ; echo
DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2
hexdump -n32 -s612k -v -e '/1 "%02X"' picture.jpg ; echo
AB9DDDBBB05CA915EE2289E59A116B02A26C82C8A8033DD8FA6D06A84B6501B7
hexdump -n32 -s1124k -v -e '/1 "%02X"' picture.jpg ; echo
BC31A8DC791ACDA4FA3E9D3406D5639619576AEE2E08C03C9EF5E23F0A7C5CBA
...

Затем мы ищем вхождения всех этих строк байтов во всех наших необработанных разделах, таким образом, всего (N + 1) * N команд, например так:

sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/sda2
sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/sdb2
...
sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/sdh2
/dev/sdh2: 52a7ff000
sudo ./bgrep AB9DDDBBB05CA915EE2289E59A116B02A26C82C8A8033DD8FA6D06A84B6501B7 /dev/sda2
/dev/sdb2: 52a87f000
...

Эти команды могут выполняться параллельно для разных дисков. Сканирование раздела на 38 ГБ заняло около 12 минут. В моем случае каждая 32-байтовая строка была найдена только один раз среди всех восьми дисков. Сравнивая смещения, возвращаемые bgrep, вы получаете такую ​​картинку:

| offset \ partition | b | d | c | e | f | g | a | h |
|--------------------+---+---+---+---+---+---+---+---|
| 52a7ff000          | P |   |   |   |   |   |   | 1 |
| 52a87f000          | 2 | 3 | 4 | 5 | 6 | 7 | 8 | P |
| 52a8ff000          |   |   |   |   |   |   | P | 9 |

Мы видим нормальную левосимметричную разметку, которая используется по умолчанию mdadm. Что еще более важно, теперь мы знаем порядок разделов. Однако мы не знаем, какой раздел является первым в массиве, поскольку они могут циклически сдвигаться.

Обратите внимание также на расстояние между найденными смещениями. В моем случае это было 512 КБ. Размер куска может фактически быть меньше, чем это расстояние, и в этом случае фактическое расположение будет другим.

Найти оригинальный размер куска

Мы используем один и тот же файл picture.jpgдля чтения 32 байтов данных с разными интервалами. Из вышеизложенного мы знаем, что данные со смещением 100k лежат /dev/sdh2, со смещением 612k равны /dev/sdb2, а на 1124k равны /dev/sdd2. Это показывает, что размер чанка не превышает 512 КБ. Мы проверяем, что он не меньше 512 КБ. Для этого мы сбрасываем строку байта со смещением 356k и смотрим, на каком разделе она расположена:

hexdump -n32 -s356k -v -e '/1 "%02X"' P1080801.JPG ; echo
7EC528AD0A8D3E485AE450F88E56D6AEB948FED7E679B04091B031705B6AFA7A
sudo ./bgrep 7EC528AD0A8D3E485AE450F88E56D6AEB948FED7E679B04091B031705B6AFA7A /dev/sdb2
/dev/sdb2: 52a83f000

Он находится в том же разделе, что и смещение 612 КБ, что указывает на то, что размер фрагмента не равен 256 КБ. Мы исключаем меньшие размеры блоков аналогичным образом. Я закончил с кусками 512 КБ, являющимися единственной возможностью.

Найти первый раздел в макете

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

Для начала мы создадим массив с правильным порядком разбиений, который мы нашли ранее:

sudo mdadm --stop /dev/md126
sudo mdadm --create /dev/md126 --assume-clean --raid-devices=8 --level=5  /dev/sdb2 /dev/sdd2 /dev/sdc2 /dev/sde2 /dev/sdf2 /dev/sdg2 /dev/sda2 /dev/sdh2

Мы проверяем, что заказ выполняется

sudo mdadm --misc -D /dev/md126
...
Number   Major   Minor   RaidDevice State
   0       8       18        0      active sync   /dev/sdb2
   1       8       50        1      active sync   /dev/sdd2
   2       8       34        2      active sync   /dev/sdc2
   3       8       66        3      active sync   /dev/sde2
   4       8       82        4      active sync   /dev/sdf2
   5       8       98        5      active sync   /dev/sdg2
   6       8        2        6      active sync   /dev/sda2
   7       8      114        7      active sync   /dev/sdh2

Теперь мы определяем смещения N + 1 известных байтов в массиве RAID. Я запускаю скрипт на ночь (Live CD не запрашивает пароль на sudo :):

#!/bin/bash
echo "1st:"
sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/md126
echo "2nd:"
sudo ./bgrep AB9DDDBBB05CA915EE2289E59A116B02A26C82C8A8033DD8FA6D06A84B6501B7 /dev/md126
echo "3rd:"
sudo ./bgrep BC31A8DC791ACDA4FA3E9D3406D5639619576AEE2E08C03C9EF5E23F0A7C5CBA /dev/md126
...
echo "9th:"
sudo ./bgrep 99B5A96F21BB74D4A630C519B463954EC096E062B0F5E325FE8D731C6D1B4D37 /dev/md126

Вывод с комментариями:

1st:
/dev/md126: 2428fff000 # 1st
2nd:
/dev/md126: 242947f000 # 480000 after 1st
3rd:                   # 3rd not found
4th:
/dev/md126: 242917f000 # 180000 after 1st
5th:
/dev/md126: 24291ff000 # 200000 after 1st
6th:
/dev/md126: 242927f000 # 280000 after 1st
7th:
/dev/md126: 24292ff000 # 300000 after 1st
8th:
/dev/md126: 242937f000 # 380000 after 1st
9th:
/dev/md126: 24297ff000 # 800000 after 1st

На основании этих данных мы видим, что 3-я строка не была найдена. Это означает, что кусок в /dev/sdd2используется для паритета. Вот иллюстрация позиций четности в новом массиве:

| offset \ partition | b | d | c | e | f | g | a | h |
|--------------------+---+---+---+---+---+---+---+---|
| 52a7ff000          |   |   | P |   |   |   |   | 1 |
| 52a87f000          | 2 | P | 4 | 5 | 6 | 7 | 8 |   |
| 52a8ff000          | P |   |   |   |   |   |   | 9 |

Наша цель - определить, с какого раздела начать массив, чтобы сдвинуть блоки четности в нужное место. Поскольку четность должна быть смещена на две части влево, последовательность разбиения должна быть смещена на два шага вправо. Таким образом, правильное расположение для этого смещения данных ahbdcefg:

sudo mdadm --stop /dev/md126
sudo mdadm --create /dev/md126 --assume-clean --raid-devices=8 --level=5  /dev/sda2 /dev/sdh2 /dev/sdb2 /dev/sdd2 /dev/sdc2 /dev/sde2 /dev/sdf2 /dev/sdg2 

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

Проверьте согласованность данных

Мы проверяем, что данные согласованы по полосе фрагментов, извлекая копию picture.jpgиз массива. Для этого мы находим смещение для 32-байтовой строки в 100k:

sudo ./bgrep DA1DC4D616B1C71079624CDC36E3D40E7B1CFF00857C663687B6C4464D6C77D2 /dev/md126

Затем мы вычтем 100 * 1024 из результата и используем полученное десятичное значение в skip=параметре для dd. count=Имеет размер picture.jpgв байтах:

sudo dd if=/dev/md126 of=./extract.jpg bs=1 skip=155311300608 count=4536208

Проверьте это так extract.jpgже, как picture.jpg.

Найти смещение данных RAID

Примечание: смещение данных по умолчанию для mdadmверсии 3.2.3 составляет 2048 секторов. Но это значение было изменено с течением времени. Если исходный массив использовал меньшее смещение данных, чем ваш текущий mdadm, то mdadm --createбез него --assume-cleanможно перезаписать начало файловой системы.

В предыдущем разделе мы создали массив RAID. Проверьте, какое смещение данных RAID имело место, выдав для некоторых отдельных разделов:

sudo mdadm --examine /dev/sdb2
...
    Data Offset : 2048 sectors
...

2048 512-байтовых секторов - 1 МБ. Поскольку размер фрагмента составляет 512 КБ, текущее смещение данных составляет два фрагмента.

Если в этот момент у вас есть сдвиг из двух частей, он, вероятно, достаточно мал, и вы можете пропустить этот абзац.
Мы создаем массив RAID5 со смещением данных в один 512 КБ-чанк. Начиная с одного фрагмента раньше, мы смещаем четность на один шаг влево, поэтому мы компенсируем это, сдвигая последовательность разбиения на один шаг влево. Следовательно, для смещения данных 512 КБ правильное расположение hbdcefga. Мы используем версию, mdadmкоторая поддерживает смещение данных (см. Раздел «Инструменты»). Смещается в килобайтах:

sudo mdadm --stop /dev/md126
sudo ./mdadm --create /dev/md126 --assume-clean --raid-devices=8 --level=5  /dev/sdh2:512 /dev/sdb2:512 /dev/sdd2:512 /dev/sdc2:512 /dev/sde2:512 /dev/sdf2:512 /dev/sdg2:512 /dev/sda2:512

Теперь мы ищем действительный суперблок ext4. Структуру суперблока можно найти здесь: https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#The_Super_Block.
Мы сканируем начало массива на наличие вхождений магического числа, s_magicза которым следуют s_stateи s_errors. Следующие строки для поиска:

53EF01000100
53EF00000100
53EF02000100
53EF01000200
53EF02000200

Пример команды:

sudo ./bgrep 53EF01000100 /dev/md126
/dev/md126: 0dc80438

Магическое число начинается с 0x38 байт в суперблок, поэтому мы вычитаем 0x38, чтобы вычислить смещение и изучить весь суперблок:

sudo hexdump -n84 -s0xDC80400 -v /dev/md126
dc80400 2000 00fe 1480 03f8 cdd3 0032 d2b2 0119
dc80410 ab16 00f7 0000 0000 0002 0000 0002 0000
dc80420 8000 0000 8000 0000 2000 0000 b363 51bd
dc80430 e406 5170 010d ffff ef53 0001 0001 0000
dc80440 3d3a 50af 0000 0000 0000 0000 0001 0000
dc80450 0000 0000                              

Это кажется правильным суперблоком. s_log_block_sizeполе в 0x18 равно 0002, что означает, что размер блока составляет 2 ^ (10 + 2) = 4096 байт. s_blocks_count_loв 0x4 - блоки 03f81480, что составляет 254 ГБ. Выглядит хорошо.

Теперь мы просматриваем вхождения первых байтов суперблока, чтобы найти его копии. Обратите внимание на переворачивание байта по сравнению с выводом hexdump:

sudo ./bgrep 0020fe008014f803d3cd3200 /dev/md126
/dev/md126: 0dc80400    # offset by 1024 bytes from the start of the FS        
/dev/md126: 15c80000    # 32768 blocks from FS start
/dev/md126: 25c80000    # 98304
/dev/md126: 35c80000    # 163840
/dev/md126: 45c80000    # 229376
/dev/md126: 55c80000    # 294912
/dev/md126: d5c80000    # 819200
/dev/md126: e5c80000    # 884736
/dev/md126: 195c80000
/dev/md126: 295c80000

Это идеально согласуется с ожидаемыми позициями резервных суперблоков:

sudo mke2fs -n /dev/md126
...
Block size=4096 (log=2)
...
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424, 20480000, 23887872

Следовательно, файловая система начинается со смещения 0xdc80000, то есть 225792KB от начала раздела. Поскольку у нас есть 8 разделов, из которых один для контроля четности, мы делим смещение на 7. Это дает смещение 33030144 байта на каждый раздел, что составляет ровно 63 фрагмента RAID. А поскольку текущее смещение данных RAID составляет один фрагмент, мы заключаем, что исходное смещение данных составляло 64 фрагмента или 32768 КБ. Сдвиг hbdcefga63 раза вправо дает расположение bdcefgah.

Наконец, мы построим правильный массив RAID:

sudo mdadm --stop /dev/md126
sudo ./mdadm --create /dev/md126 --assume-clean --raid-devices=8 --level=5  /dev/sdb2:32768 /dev/sdd2:32768 /dev/sdc2:32768 /dev/sde2:32768 /dev/sdf2:32768 /dev/sdg2:32768 /dev/sda2:32768 /dev/sdh2:32768
sudo fsck.ext4 -n /dev/md126
e2fsck 1.42 (29-Nov-2011)
Warning: skipping journal recovery because doing a read-only filesystem check.
/dev/md126: clean, 423146/16654336 files, 48120270/66589824 blocks
sudo mount -t ext4 -r /dev/md126 /home/xubuntu/mp

Вуаля!

У меня была похожая проблема. Я отформатировал и переустановил мой OS / загрузочный диск с чистой установкой Ubuntu 12.04, затем запустил команду mdadm --create ... и не смог ее смонтировать.

Он сказал, что не имеет действительного суперблока или раздела.

Более того, когда я остановил рейд mdadm, я больше не мог монтировать обычное устройство.

Я смог восстановить суперблок с помощью mke2fs и e2fsck:

root@blackbox:~# mke2fs -n /dev/sdc1
mke2fs 1.42 (29-Nov-2011)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
91578368 inodes, 366284000 blocks
18314200 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
11179 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
  32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
  4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
  102400000, 214990848

Затем побежал:

e2fsck -b 32768 -y /dev/sdc1

Это восстановило суперблок, чтобы я мог смонтировать и прочитать диск.

Чтобы заставить массив работать без разрушения суперблока или разделов, я использовал build:

mdadm --build /dev/md0 --level=mirror --assume-clean --raid-devices=2  /dev/sdc1 missing 

После проверки данных я добавлю другой диск:

mdadm --add /dev/md0 /sdd1

Я просто обновляю часть информации, приведенной ранее. Когда умерла моя материнская плата, у меня был трехдисковый массив raid5, работающий нормально. Массив содержит / dev / md2 в качестве раздела / home размером 1,2 ТБ и / dev / md3 в качестве раздела / var 300 ГБ.

У меня было две резервные копии «важных» вещей и куча случайных вещей, которые я взял из разных частей интернета, которые я действительно должен был пройти и выборочно выбросить. Большинство резервных копий были разбиты на файлы .tar.gz размером 25 ГБ или менее, а также была скопирована отдельная копия / etc.

Остальная часть файловой системы содержалась на двух маленьких дисках raid0 объемом 38 ГБ.

Моя новая машина была похожа на старое оборудование, и я запустил машину и включил ее, просто подключив все пять дисков и выбрав старое общее ядро. Таким образом, у меня было пять дисков с чистыми файловыми системами, хотя я не мог быть уверен, что диски были в правильном порядке, и мне нужно было установить новую версию Debian Jessie, чтобы быть уверенным, что я смогу обновить машину при необходимости и разобраться с другими проблемы.

С новой универсальной системой, установленной на двух дисках Raid0, я начал собирать массивы обратно. Я хотел быть уверен, что у меня были диски в правильном порядке. Что я должен был сделать, это выдать:

mdadm --assemble /dev/md3 -o --no-degraded --uuid=82164ae7:9af3c5f1:f75f70a5:ba2a159a

Но я не сделал. Кажется, что mdadm довольно умен и, имея uuid, может выяснить, какие диски куда идут. Даже если bios назначит / dev / sdc как / sda, mdadm соберет его правильно (хотя YMMV).

Вместо этого я mdadm --create /dev/md2 without the --assume-cleanввел : и разрешил повторную синхронизацию в / dev / sde1. Следующая ошибка, которую я допустил, заключалась в том, чтобы работать с / dev / sdc1 вместо последнего диска в / dev / md2, / sde1. Каждый раз, когда mdadm думает, что есть проблема, это последний диск, который выгружается или повторно синхронизируется.

После этого mdadm не смог найти ни одного суперблока, и e2fsck -n тоже не смог.

После того, как я нашел эту страницу, я прошел процедуру, пытаясь найти последовательность для дисков (сделано), проверить правильность данных (проверено 6 МБ файла 9 МБ), получил диски в правильной последовательности, cde, взял uuid / md2 и / md3 из старого /etc/mdadm.conf и попытался собрать.

Ну что ж, /dev/md3запустил и mdadm --misc -D /dev/md3показал три здоровых раздела и диски в правильном порядке. /dev/md2также выглядел хорошо, пока я не попытался смонтировать файловую систему.

# mdadm --create /dev/md2 --raid-devices=3 --level=5 --uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7 /dev/sdc1 /dev/sdd1 /dev/sde1
mdadm: /dev/sdc1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
mdadm: /dev/sdd1 appears to contain an ext2fs file system
       size=585936896K  mtime=Thu Jan  1 01:00:00 1970
mdadm: /dev/sdd1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
mdadm: /dev/sde1 appears to contain an ext2fs file system
       size=585936896K  mtime=Thu Jan  1 01:00:00 1970
mdadm: /dev/sde1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md2 started.

Файловая система отказалась монтироваться, и e2fsck не смог найти никаких суперблоков. Кроме того, при проверке на наличие суперблоков, как описано выше, общее число блоков, найденное как a880 0076 или a880 0076 или 5500 1176, не соответствовало размеру дискового пространства 1199,79, сообщило мой mdadm. Также ни одно из мест расположения «суперблоков» не выровнено с данными в постах выше.

Я скопировал все / var и приготовился стереть диски. Чтобы увидеть, можно ли было просто стереть / md2 (мне больше нечего было терять на этом этапе), я обнаружил следующее:

root@ced2:/home/richard# mdadm --create /dev/md2 --raid-devices=3 --level=5 --uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7 /dev/sdc1 /dev/sdd1 /dev/sde1
mdadm: /dev/sdc1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
mdadm: /dev/sdd1 appears to contain an ext2fs file system
       size=585936896K  mtime=Thu Jan  1 01:00:00 1970
mdadm: /dev/sdd1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
mdadm: /dev/sde1 appears to contain an ext2fs file system
       size=585936896K  mtime=Thu Jan  1 01:00:00 1970
mdadm: /dev/sde1 appears to be part of a raid array:
       level=raid5 devices=3 ctime=Wed Feb  3 14:05:36 2016
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md2 started.
# mkfs.ext3 /dev/md2
mke2fs 1.42.12 (29-Aug-2014)
Creating filesystem with 292902912 4k blocks and 73228288 inodes
Filesystem UUID: a54e252f-78db-4ebb-b7ca-7dcd2edf57a4
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
    102400000, 214990848

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done 


# hexdump -n84 -s0x00000400 -v /dev/md2
0000400 6000 045d 5800 1175 7799 00df 6ff0 112e
0000410 5ff5 045d 0000 0000 0002 0000 0002 0000
0000420 8000 0000 8000 0000 2000 0000 10d3 56b2
0000430 10d3 56b2 0002 ffff ef53 0001 0001 0000
0000440 0c42 56b2 0000 0000 0000 0000 0001 0000
0000450 0000 0000                              
0000454

#  ./bgrep 00605D0400587511 /dev/md2
/dev/md2: 00000400
/dev/md2: 08000000
/dev/md2: 18000000
/dev/md2: 28000000
/dev/md2: 38000000
/dev/md2: 48000000
/dev/md2: c8000000
/dev/md2: d8000000
/dev/md2: 188000000
/dev/md2: 288000000
/dev/md2: 3e8000000
/dev/md2: 798000000
/dev/md2: ab8000000
etc

Казалось, все в порядке, за исключением изменения в uuid. Поэтому после еще нескольких проверок я записал 600 ГБ резервных копий данных в / dev / md2. Затем размонтировали и попытались снова смонтировать диск:

# mdadm --assemble /dev/md2 uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7
mdadm: cannot open device uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7: No such file or directory
mdadm: uuid=c0a644c7:e5bcf758:ecfbc8f3:ee0392b7 has no superblock - assembly aborted

Ты шутишь, что ли? как насчет моих 600 ГБ в файле?

# mdadm --assemble /dev/md2 
mdadm: /dev/md2 not identified in config file.

Ах, это легко исправить. раскомментированная строка в /etc/mdadm.conf

# mdadm --assemble /dev/md2 
mdadm: /dev/md2 has been started with 3 drives.

# e2fsck -n /dev/md2
e2fsck 1.42.12 (29-Aug-2014)
/dev/md2: clean, 731552/73228288 files, 182979586/292902912 blocks

Yippie!