LINUX.ORG.RU
ФорумAdmin

Упал RAID10

 


0

1

Есть сервак с 4 винтами и несколькими рейдами. Упал один из рейдов. На нем важные данные. Не могу восстановить. Итак имеем.

Centos 6.5

 cat /proc/mdstat
Personalities : [raid1] [raid10] [raid0]
md3 : active raid10 sdd5[3] sdc5[2] sdb5[1] sda5[0]
      199973888 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]

ФС ext4.

Пробовал

 
mdadm --stop /dev/md3
mdadm --create /dev/md3 -v --assume-clean --level=10  --raid-devices=4 /dev/sda5 /dev/sdb5 /dev/sdc5 /dev/sdd5 

Потом пытаюсь монтировать и получаю

 
 mount -a
mount: wrong fs type, bad option, bad superblock on /dev/md3,
       missing codepage or helper program, or other error
tail -n 5 /var/log/messages
Aug 24 11:39:53 virtual kernel: [36729.899447] md/raid10:md3: active with 4 out of 4 devices
Aug 24 11:39:53 virtual kernel: [36729.899469] md3: detected capacity change from 0 to 204773261312
Aug 24 11:39:53 virtual kernel: [36729.899556]  md3: unknown partition table
Aug 24 11:41:59 virtual kernel: [36855.542547] EXT4-fs (md3): VFS: Can't find ext4 filesystem
Aug 24 11:53:45 virtual kernel: [37562.178259] EXT4-fs (md3): VFS: Can't find ext4 filesystem

Пытаюсь запустить проверку

fsck /dev/md3
fsck from util-linux-ng 2.17.2
e2fsck 1.41.12 (17-May-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/md3

Ладно. смотрим номер блоков

mke2fs  -n /dev/md3
mke2fs 1.41.12 (17-May-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=128 blocks, Stripe width=256 blocks
12500992 inodes, 49993472 blocks
2499673 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
1526 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
и пробуем еще раз
e2fsck -b 32768 /dev/md3
e2fsck 1.41.12 (17-May-2010)
e2fsck: Bad magic number in super-block while trying to open /dev/md3

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>

И так с любым блоком. Дальше у меня идею уже закончились. Есть идеи?

★★

mdadm --create /dev/md3

Теперь только бакапы. Надо было --assemble

AS ★★★★★ ()
Ответ на: комментарий от axelroot

Задним умом все умные, я знаю) Но скрипт бекапа с какого-то момента перестал делать эти самые бекапы. А то что есть старое. Мне бы именно проблему рейда решить. Думаю все-таки его можно привести в чувства. Видимо просто таблица разделов слетела. Но как ее восстановить?

as_lan ★★ ()
Ответ на: комментарий от as_lan

Видимо просто таблица разделов слетела. Но как ее восстановить?

В теории, --create мог не всё стереть. Может бы и можно как-то восстановить метаданные на всех разделах и собрать RAID. Не знаю, какую часть затирает --create на разделах.

AS ★★★★★ ()
Ответ на: комментарий от as_lan

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

https://ru.wikipedia.org/wiki/TestDisk

во блин именно десятку тестдиск и не умеет.

axelroot ()
Последнее исправление: axelroot (всего исправлений: 1)
Ответ на: комментарий от as_lan

тестдиск к слову сразу. не видит ничего.

там же написано рейд десятку он не могет.

axelroot ()
Ответ на: комментарий от axelroot

Да два (какие именно не знаю, так как меня в этот момент на месте не было). Переткнули. Решили по новой добавить их в рейд, но не выходило. Потом попробовали --create. Но как теперь выяснилось он затирает.

as_lan ★★ ()
Ответ на: комментарий от as_lan

если на одном из дисков рейда слетела таблица разделов, очевидно, рейд восстановит её с другого диска?

darkenshvein ★★★★★ ()
Ответ на: комментарий от as_lan

Да два

50% вероятность шо данным полный херздец, десятка гарантирует сохранность данных только при выпадении 1 диска из 4-х.

axelroot ()
Ответ на: комментарий от axelroot

Ну об этом я в курсе. Но по смарту ничего криминального в дисками не случилось. Может просто на программном уровне что-то случилось и диски вылетели. Физически данные не должны были же пострадать.

as_lan ★★ ()
Ответ на: комментарий от targitaj

Как бы сделали в мое отсутствие. Я сам тоже не рад тому что это сделали и когда услышал это сразу в голове были мысли что create наверняка что-то затирает.

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

as_lan ★★ ()
Последнее исправление: as_lan (всего исправлений: 1)
Ответ на: комментарий от targitaj

LVM было?

Особенно это касается LVM over linux-raid. Лично я не сталкивался, у меня камрад наелся вдоволь. Камрад не дурак.

Хорошая попытка, но не повезло твоему комраду, так и останется не «не дурак»

anonymous ()
Ответ на: комментарий от as_lan

после create вероятно все очень плохо, а вот c теми дисками, которые вытащили можно попробовать восстановить

anonymous ()
Ответ на: комментарий от lu4nik

при выпадении и двух дисков

50/50 что ФС содержит кашу.

axelroot ()
Ответ на: комментарий от anonymous

Был бы ты умным и знал бы что-то на самом деле - то помог бы камраду as_lan. Помощь не наблюдается. Вывод очевиден.

targitaj ★★★★★ ()
Ответ на: комментарий от targitaj

Кто-то уже помог? Ты всех назвал очевидно ... ? Скажи вслух.

anonymous ()
mdadm --stop /dev/md3
mdadm --create /dev/md3 -v --assume-clean --level=10  --raid-devices=4 /dev/sda5 /dev/sdb5 /dev/sdc5 /dev/sdd5

По хорошему, при пересоздании рейда на тех же дисках нужно всегда явно указывать версию метаданных (-e, --metadata). Иначе есть риск, что новый блок с метаданными запишется на диски не туда. Это может сделать ФС нечитаемой и повредить данные.

Deleted ()
Ответ на: комментарий от Deleted

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

Короче не надо так делать, если нет уверенности, что всё делаешь абсолютно правильно 8).

Deleted ()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

Что сделано то сделано) сейчас то можно восстановить? Порядок дисков при создании какой был уже не вспомнить, так как создавали рейд пару лет назад.

as_lan ★★ ()
Ответ на: комментарий от as_lan

я бы сделал бэкапы того что осталось (просто dd с дисков/разделов на другое хранилище). А потом попробовал разные комбинации порядка дисков и метаданных. Шанс небольшой, но всё же...

Deleted ()
Ответ на: комментарий от Deleted

Ах да, ещё после --stop и перед --create надо было сделать --zero-superblock на все диски.

И что, при соблюдении этих условий данные бы не пропали ? Или переписалось бы строго своё, без попадания в область данных, где ФС начинается ? Вообще, может быть. Тогда, вероятно, и не всё потеряно ещё, если начать варианты перебирать.

AS ★★★★★ ()
Ответ на: комментарий от as_lan

Решили по новой добавить их в рейд, но не выходило.

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

Хотя, сейчас, если с восстановлением метаданных прокатит, это может быть тоже актуально. Так что, сначала бакап всех 4-х, как уже советовали.

AS ★★★★★ ()
Ответ на: комментарий от AS

так create ведь уже сделан.

Мне другое непонятно. Почему ругается на суперблок? Даже когда явно указываю их.

as_lan ★★ ()
Ответ на: комментарий от as_lan

Почему ругается на суперблок ?

Если mironov_ivan прав, и --create не лезет в область данных, то, видимо, диски перепутаны. Соответственно, ничего, что похоже на ФС, там нет. Диски вынимались ? Если да, вставлены точно, как было ?

AS ★★★★★ ()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от AS

И что, при соблюдении этих условий данные бы не пропали ? Или переписалось бы строго своё, без попадания в область данных, где ФС начинается ?

Да. С --assume-clean данные не перезаписываются. Только блок метаданных.

Deleted ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.