Вопросы Теги

Восстановите данные RAID 5 после созданного нового массива вместо многократного использования

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

Возможно, существует что-то подобное инструментам VMware, которые необходимо установить в VM?

35
задан 19 January 2012 в 01:23
5 ответов

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

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

5
ответ дан 28 November 2019 в 19:51

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

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

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

По предложениям я очистил суперблоки и воссоздал массив с параметром --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

Хорошо. У нас есть файловая система и некоторые данные («данные» в ​​файле данных и 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

Solid - никаких повреждений данных! Но это с точно такими же настройками, поэтому ничто не было сопоставлено по-разному между двумя группами 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 тысяч знаков; 8k + вне предела длины

89
ответ дан 28 November 2019 в 19:51

У меня была аналогичная проблема. Я отформатировал и переустановил свою ОС / загрузочный диск с помощью чистой установки 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
0
ответ дан 28 November 2019 в 19:51

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

Long Story Short

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

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

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

Предварительные требования

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

Инструменты

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

версия 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 и шестнадцатеричный калькулятор - стандартные инструменты из репозиториев

Start with Full Backup

Именование файлов устройств, например / 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 позициях, начиная со 100k и увеличиваясь на 512k: 

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

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

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

Теперь мы знаем порядок разделов, но не t знать, какой раздел должен быть первым и какое смещение данных 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 без - Предположим, чистый может перезаписать начало файла система.

В предыдущем разделе мы создали 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 ГБ. Выглядит хорошо.

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

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, т.е. 225792 КБ от начала раздела. Поскольку у нас есть 8 разделов, из которых один предназначен для контроля четности, мы делим смещение на 7. Это дает смещение 33030144 байта для каждого раздела, что составляет ровно 63 фрагмента RAID. А поскольку текущее смещение данных RAID составляет один фрагмент, мы заключаем, что исходное смещение данных составляло 64 фрагмента, или 32768 КБ. Сдвиг hbdcefga 63 раза вправо дает макет 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

Voilà!

5
ответ дан 28 November 2019 в 19:51

Я просто обновляю некоторую информацию, приведенную ранее. Когда моя материнская плата умерла, 3-дисковый рейдовый массив5 работал нормально. Массив содержал /dev/md2 в качестве раздела /home 1.2ТБ и /dev/md3 в качестве раздела /var 300GB.

У меня было два бэкапа "важных" вещей и куча случайных вещей, которые я взял из различных частей интернета, которые я действительно должен был пройти и выборочно выбросить. Большинство резервных копий были разбиты на файлы .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 --creatate /dev/md2 без --assume-clean , и позволил завершить ресинхронизацию на /dev/sde1. Следующей ошибкой, которую я сделал, была работа с /dev/sdc1 вместо последнего диска в /dev/md2, /sde1. Всякий раз, когда mdadm думает, что есть проблема, это последний диск, который выгнали или пересинхронизировали.

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

После того, как я нашел эту страницу, я прошел процедуру попытки найти последовательность дисков (сделано), проверил действительные данные (проверено 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!

0
ответ дан 28 November 2019 в 19:51

Теги

Похожие вопросы