Восстановление программного обеспечения Linux RAID
Я вижу расхождение между выводом mdadm --detail и mdadm --examine, и я не понимаю, почему.
Этот вывод
mdadm --detail /dev/md2
/dev/md2:
Version : 0.90
Creation Time : Wed Mar 14 18:20:52 2012
Raid Level : raid10
Array Size : 3662760640 (3493.08 GiB 3750.67 GB)
Used Dev Size : 1465104256 (1397.23 GiB 1500.27 GB)
Raid Devices : 5
Total Devices : 5
Preferred Minor : 2
Persistence : Superblock is persistent
Кажется, противоречит этому. (одинаково для каждого диска в массиве)
mdadm --examine /dev/sdc2
/dev/sdc2:
Magic : a92b4efc
Version : 0.90.00
UUID : 1f54d708:60227dd6:163c2a05:89fa2e07 (local to host)
Creation Time : Wed Mar 14 18:20:52 2012
Raid Level : raid10
Used Dev Size : 1465104320 (1397.23 GiB 1500.27 GB)
Array Size : 2930208640 (2794.46 GiB 3000.53 GB)
Raid Devices : 5
Total Devices : 5
Preferred Minor : 2
Массив был создан следующим образом.
mdadm -v --create /dev/md2 \
--level=raid10 --layout=o2 --raid-devices=5 \
--chunk=64 --metadata=0.90 \
/dev/sdg2 /dev/sdf2 /dev/sde2 /dev/sdd2 /dev/sdc2
Каждый из 5 отдельных дисков имеет такие разделы.
Disk /dev/sdc: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders, total 2930277168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00057754
Device Boot Start End Blocks Id System
/dev/sdc1 2048 34815 16384 83 Linux
/dev/sdc2 34816 2930243583 1465104384 fd Linux raid autodetect
Предыстория
Поэтому контроллер SATA вышел из строя в коробке, для которой я предоставляю некоторую поддержку. Сбой был ужасным, и поэтому отдельные диски постепенно выпадали из массива. В то время как есть резервные копии, мы на самом деле не делаем так часто, как нам действительно нужно. Есть некоторые данные, которые я пытаюсь восстановить, если смогу.
Я получил дополнительное оборудование и снова смог получить доступ к дискам. Диски в порядке, и я могу активировать и смонтировать массив и файловую систему (используя режим только для чтения). Я могу получить доступ к некоторым данным в файловой системе и копирую их, но я вижу много ошибок, когда пытаюсь скопировать самые последние данные.
Когда я пытаюсь получить доступ к этим самым последним данным, я получаю ошибки, подобные приведенным ниже, из-за которых я думаю, что проблема может быть связана с несоответствием размера массива.
Mar 14 18:26:04 server kernel: [351588.196299] dm-7: rw=0, want=6619839616, limit=6442450944
Mar 14 18:26:04 server kernel: [351588.196309] attempt to access beyond end of device
Mar 14 18:26:04 server kernel: [351588.196313] dm-7: rw=0, want=6619839616, limit=6442450944
Mar 14 18:26:04 server kernel: [351588.199260] attempt to access beyond end of device
Mar 14 18:26:04 server kernel: [351588.199264] dm-7: rw=0, want=20647626304, limit=6442450944
Mar 14 18:26:04 server kernel: [351588.202446] attempt to access beyond end of device
Mar 14 18:26:04 server kernel: [351588.202450] dm-7: rw=0, want=19973212288, limit=6442450944
Mar 14 18:26:04 server kernel: [351588.205516] attempt to access beyond end of device
Mar 14 18:26:04 server kernel: [351588.205520] dm-7: rw=0, want=8009695096, limit=6442450944
2 ответа
Если вы можете клонировать диски с помощью dd, я бы это сделал. Держите ваши оригинальные диски как можно нетронутыми.
Тогда это полный выстрел из бедра, но я бы попробовал, если бы оказался в такой ситуации. С клонированными дисками в системе я бы стер все метаданные RAID, используя.mdadm --zero-superblock /dev/sdx#
на каждом из задействованных дисков.
Затем используйте команду для воссоздания массива.mdadm -v --create /dev/md2 \
--level=raid10 --layout=o2 --raid-devices=5 \
--chunk=64 --metadata=0.90 --assume-clean \
/dev/sdg2 /dev/sdf2 /dev/sde2 /dev/sdd2 /dev/sdc2
Это должно избавить от всех проблем уровня рейда. Оттуда вы можете попробовать перемонтировать файловые системы и посмотреть, что осталось. И если это не сработает, тогда клонируйте ваши диски и попробуйте что-нибудь еще:)
Вы уверены в своей командной строке для создания массива? Я предполагаю, что это был "стандартный" 4-х дисковый массив raid10 с горячим резервным диском, который объяснял бы результат /dev/sdc2
Можете ли вы сказать нам результат:
cat /proc/mdstat
cat /etc/mdadm.conf
mdadm --examine /dev/sdx2 ( each drive )
При этом вы сможете угадать, какой диск был горячим резервом, и вы сможете правильно восстановить массив. Конечно, как утверждает 3dinfluence, вы должны продублировать данные, прежде чем пытаться перенастроить массив.
Изменить: также, вероятно, это не пустая трата времени для запуска:smartctl -a /dev/sdx на каждом диске (проверьте в конце вывода, были ли обнаружены ошибки), а затем smartcl -t long /dev/sdx и через 3 или 4 часа Smartctl -a снова, чтобы проверить, что 5 дисков действительно в порядке. Если один диск сообщает об ошибках, возможно, mdadm обнаружил, что он неисправен, и поэтому mdadm включил запасной диск (всегда предположение)
Редактировать 2: если отчеты vgs: vgdisplay показывает Alloc PE/ размер 3,00 ТБ, свободный PE / размер 421,08 Это означает, что ваш PV таинственным образом вырос до 421G . Я придерживаюсь моего мнения: рост "таинственный" является неправильной конфигурацией вашего массива, Реальный размер вашего массива - 3T. Вы неправильно собрали его, поэтому он поврежден. Чтобы правильно собрать его, вам нужно восстановить исходную конфигурацию и указать, какой из дисков был запасным. Удачи.