затерся суперблок, не востанавливается LVM (софтверный рейд 10)

Собери RAID10 с опцией assume-clean. Если правильно подберешь порядок винтов, будет тебе счастье. Но если при предыдущем запуске он успел затереть метаданные LVM - ты в жопе.

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

Надо было сначала подумать, потом прочитать документацию, потом подумать, потом погуглить, снова подумать и только потом делать. Особенно в таких ответственных моментах...

Поняв что что то явно не так - отменил установку (ребилд новерняка даже толком начаться не успел).

Надейся на лучшее, но готовься... ну ты понял.

UUID не совпадает со старым.

Это логично. При создании массива всегда выбирается свежий UUID.

А теперь более по теме. Если тебе страшно повезло и инсталлятор успел только пересоздать RAID (без ресинхронизации), то максимум что случилось - это затёрлась пара десятков килобайт в тех местах, куда mdadm записал новые метаданные. Раз после подцепления нового массива система не увидела твой LVM, значит либо метаданные были записаны в другое место (читай man mdadm на предмет версии, там в разных версиях метаданные в разных частях раздела лежат), либо диски были собраны не в том же порядке, в котором они были раньше, либо часть данных таки затёрлась. Скорее всего тебе нужно снова пересоздать массив с помощью mdadm, причём точно так же, как это когда-то сделать инсталлятор альта. Важно, чтобы диски шли в том же порядке и метеданные были в том же месте.

Теперь переходим к LVM. Если после *правильно* пересозданного RAID'а система так и не увидела LVM, значит новые метаданные RAID'а таки затёрли метаданные LVM (вообще все?! но мы всё-равно надеемся на лучшее). Копия всех метаданные LVM лежала в /etc/lvm в виде текстового файлика (посмотри для примера на живой системе). По идее, можно при помощи grep, dd, hex-редактора и такой-то матери найти на твоих дисках этот файлик и при помощи него восстановить LVM.

Если это не помогло, то можно воспользоваться photorec. Он восстановит далеко не всё и с неправильными имени, но хоть что-то. Можно поискать платные проприетарные программы. Можно обратиться к специалистам в соответствующие фирмы, но это будет дорого, особенно в таком «экзотическом» случае как linux + raid + lvm.

P.S. Вообще, очень рекомендую перед тем как что-либо предпринимать, найти пачку таких же дисков и скопировать туда всё содержимое имеющихся дисков при помощи dd.

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

d-i находит и запускает все доступные массивы автоматически. Раз этого не случилось, что-то там было не так.

>> метаданные RAID'а таки затёрли метаданные LVM

Крайне маловероятно. Суперблок mdraid, расположенный в начале устройства, имеет размер всего 8 Кб, ЕМНИП, в то время как суперблок LVM — десятки, с сохранением множества изменений (если я правильно понял дамп).

>> Если тебе страшно повезло и инсталлятор успел только пересоздать RAID (без ресинхронизации)

Ресинхронизация начинается сразу же после создания массива.

>> Надо было сначала подумать, потом прочитать документацию, потом подумать, потом погуглить, снова подумать и только потом делать.

+1 :)

Суперблок mdraid, расположенный в начале устройства

Расположение суперблока зависит от версии формата метаданных.

Можешь мне не рассказывать, я читал спецификацию on-disk формата :)

А в Squeeze как раз используется по умолчанию 1.2 (4 Kb от начала блочного устройства).

спасибо всем отписавшимся. рейд пересоздал, порядок такой же как и первоначальный. выводы pvdisplay и vgscan не изменились(т.е. pvdisplay говорит что метаданные повреждены, но находит проинициализированный на данном рейде раздел. vgscan ничего не находит)

Теперь переходим к LVM. Если после *правильно* пересозданного RAID'а система так и не увидела LVM, значит новые метаданные RAID'а таки затёрли метаданные LVM (вообще все?! но мы всё-равно надеемся на лучшее). Копия всех метаданные LVM лежала в /etc/lvm в виде текстового файлика (посмотри для примера на живой системе). По идее, можно при помощи grep, dd, hex-редактора и такой-то матери найти на твоих дисках этот файлик и при помощи него восстановить LVM.

файлы конфигурации lvm есть (папочка /etc/lvm доступна-система не на рейд установлена), однако vgcfgrestore не отрабатывает

# vgcfgrestore vgserver
File descriptor 3 left open
File descriptor 5 left open
File descriptor 7 left open
  Incorrect metadata area header checksum
  Incorrect metadata area header checksum
  Incorrect metadata area header checksum
  Restore failed.

поможет ли пересоздание lvm? (pvcreate -u «uuid из бекапа»)

>поможет ли пересоздание lvm? (pvcreate -u «uuid из бекапа»)

Да, должно помочь.

НО. Ты твёрдо уверен, что собрал software raid правильно? С той же версией метаданных и тем же layout?

спасибо. уже восстановил. 1. пересобрал рейд с опцией --assume-clean. 2. пресоздал lvm из бекапа с /etc/lvm. после этого определились и подобрались диски xfs_repair предложил подмонтировать их. файлы битые были но наиболее важное удалось перенести на внешку. впринципе отделался легким испугом) всем спасибо.