Ребята, пожалуйста, помогите - я новичок, с большой головной болью (идеальная ситуация шторма).
У меня есть жесткий диск емкостью 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
Интересно, что раньше имя было raid, а не host hame с добавленным: 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
Предложение Per Shanes, которое я попробовал
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
чтобы увидеть, есть ли там ваша оригинальная сборка.
Итак, список того, что вам следует сделать:
dd
прежде чем что-либо делать !!fsck
текущий активный мд - возможно, вы просто строили в том же порядке, что и раньше. Если вы знаете тип файловой системы, это полезно; использовать этот конкретный fsck
инструмент. Если какой-либо из инструментов предлагает что-то исправить, не позволяйте им, если вы не уверены, что они действительно нашли действительную файловую систему! Если fsck
предлагает что-то исправить для вас, не стесняйтесь оставлять комментарии, чтобы спросить, действительно ли это помогает или вот-вот уничтожит данные./proc/mdstat
, тогда вы можете просто имитировать то, что он показывает; если нет, то вы как бы в неведении - попробовать все различные порядки дисков разумно, но проверять каждый возможный размер блока с каждым возможным порядком бесполезно. Для каждого, fsck
это, чтобы увидеть, есть ли у вас что-нибудь многообещающее.Итак, вот и все. Извините за роман, не стесняйтесь оставлять комментарии, если у вас есть какие-либо вопросы, и удачи!
сноска: до 22 тысяч знаков; 8k + меньше предела длины
У меня была похожая проблема:
после отказа программного массива RAID5 я уволил mdadm --create
не давая это --assume-clean
, и больше не может смонтировать массив. После двух недель копания я наконец восстановил все данные. Надеюсь, описанная ниже процедура сэкономит чье-то время.
Проблема была вызвана тем, что mdadm --create
создал новый массив, который отличался от оригинала в двух аспектах:
Как было показано в блестящем ответ Шейна Мэддена, 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 и шестнадцатеричный калькулятор - стандартные инструменты из репозиториев
Именование файлов устройства, например /dev/sda2
/dev/sdb2
и т. д., не является постоянным, поэтому лучше записать серийные номера ваших дисков, указанные
sudo hdparm -I /dev/sda
Затем подключите внешний жесткий диск и создайте резервную копию каждого раздела вашего RAID-массива следующим образом:
sudo dd if=/dev/sda2 bs=4M | gzip > serial-number.gz
Здесь описаны различные макеты: 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
Он находится в том же разделе, что и смещение 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
.
Примечание: смещение данных по умолчанию для 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, т.е. 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
Вуаля!
Если ты счастливый Возможно, вам удастся вернуть файлы с помощью программного обеспечения для восстановления, которое может читать сломанный массив RAID-5. Восстановление с нулевым предположением это тот, с которым я добился успеха раньше.
Однако я не уверен, закончился ли процесс создания нового массива и уничтожил ли все данные, так что это может быть последний шанс.
У меня была аналогичная проблема. Я отформатировал и переустановил свою ОС / загрузочный диск с чистой установкой 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
Я просто обновляю некоторую информацию, данную ранее. У меня был 3-дисковый массив 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
Йиппи!