# Fake RAID1 + LVM2 = сдох драйв, LVM2 перестал работать [Slv]

## fank

Всем привет.

Есть сервер с очень критическими данными. Нужно срочно восставновить.

Ставился на полусофтовый RAID1, который на матери

после него накатили CentOS, который поставил все на LVM2 раздел

ФС - ext3

в компе всего 3 винта, на один, который без этого рэйда, была поставлена собственно система

на второй и третий, которые в рэйде - отдельный раздел под данные

ситуация такая, что умер один веник из рэйда, котрый был быстро заменен

после ребилда рэйда система грузится с нормального рабочего винта, но не видит раздел LVM2 с данными

------------------------------

VolGroup00\LogVolume00   --- это система

VolGroup00\LogVolume01   --- это своп

------------------------------

VolGroup01\LogVolume03   --- это должен быть раздел с данными

после длительных поисков решения была применена команда

```
vgcfgrestore /etc/lvm/archive/некий_бэкап.vg
```

теперь стал виден VolGroup01, в котором нет logical volume

lvscan ничего не видит

прикол в том, что система видит веники из рэйда ОБА

после применения команды 

```
dmraid -a y
```

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

нужно просто достать данные, которых немного

плевать как, хоть dd

я так понимаю, что LVM  - просто область экстентов на диске, где развернута ФС

как её найти?

я бы сделал dd if=/dev/один_из_рэйдовых_веников of=/dev/image_file.img skip=здесь_начало_раздела_LVM2 bs=some count=some

что можно сделать в данной ситуации?

----------

## ba

после

```
dmraid -a y
```

неплохо бы увидеть вывод

```
pvscan

vgscan

lvscan
```

и dmesg

ну и еще попробуй

```
lvm vgchange -a y

lvm vgmknodes
```

вдруг найдет и соберет...

еще вопрос - 

```
vgcfgrestore /etc/lvm/archive/некий_бэкап.vg
```

делалось до dmraid -a y или после?

----------

## fank

ок, отвечаю по пунктам

vgcfgrestore делался ДО dmraid -a y

ДО vgcfgrestore я сделал pvchange --uuid

соответственно, бэкап восстановился хез куда, насколько я понял

последняя команда - dmraid -a y

теперь стал виден /dev/mapper/jmicronRAID (кстати, с кучей непонятных символов после RAID, но бог с ним)

ситуация такая

ЕДИНОГЛАСНО ПРОКЛЯЛИ галимый недоРЭЙД, распаянный на матери

накатил я бэкап, сделал нормальный софтовый рэйд

инфу восстановить нужно во что бы то ни стало

сделал 10 гиг raw бэкап с помощью dd с одного из этих веников

есть оба винта, что были в рэйде

щас подсоединю веники и сделаю вывод команд

----------

## fank

подсоединил веник

```

localhost ~ # vgscan

  Reading all physical volumes.  This may take a while...

localhost ~ # lvscan

localhost ~ # pvscan

  PV /dev/sda1                      lvm2 [298.06 GB]

  Total: 1 [298.06 GB] / in use: 0 [0   ] / in no VG: 1 [298.06 GB]

localhost ~ # vgscan

  Reading all physical volumes.  This may take a while...

# pvdisplay

  "/dev/sda1" is a new physical volume of "298.06 GB"

  --- NEW Physical volume ---

  PV Name               /dev/sda1

  VG Name

  PV Size               298.06 GB

  Allocatable           NO

  PE Size (KByte)       0

  Total PE              0

  Free PE               0

  Allocated PE          0

  PV UUID               vgZkNq-6BE5-cONH-NhJX-m2NR-oZl7-HxO27P

```

```
localhost ~ # lvm vgchange -a y

localhost ~ # lvm vgmknodes

  /proc/misc: No entry for device-mapper found

  Is device-mapper driver missing from kernel?

  Failure to communicate with kernel device-mapper driver.

  /proc/misc: No entry for device-mapper found

  Is device-mapper driver missing from kernel?

  Failure to communicate with kernel device-mapper driver.

  Incompatible libdevmapper 1.02.27 (2008-06-25)(compat) and kernel driver

```

----------

## fank

сделал

```
localhost ~ # modprobe dm-mod

localhost ~ # lvm vgmknodes

localhost ~ #

localhost ~ # lvscan

localhost ~ # pvscan

  PV /dev/sdb1                      lvm2 [298.06 GB]

  Total: 1 [298.06 GB] / in use: 0 [0   ] / in no VG: 1 [298.06 GB]

localhost ~ # vgscan

  Reading all physical volumes.  This may take a while...

localhost ~ #

```

----------

## ba

 *fank wrote:*   

> ДО vgcfgrestore я сделал pvchange --uuid

 

а зачем? на какой девайс?

 *fank wrote:*   

> подсоединил веник

 

какой? если тот на котором был рейд, то я не уверен насчет того где dmraid хранит метаданные, в начале или в конце диска...

 *fank wrote:*   

> 
> 
> ```
> 
> localhost ~ # pvscan
> ...

 

это то что было на рейде?

 *fank wrote:*   

> 
> 
> ```
> localhost ~ # lvm vgchange -a y
> 
> ...

 

а lvm-то в ядре есть? что-то это все очень странно...

вобщем когда pvscan будет видеть столько же физикал девайсов как было в изначальном lvm-е и проверишь lvm в ядре, то сделай снова коммынды ручно сборки lvm-a ^^^

если не будет собирать, но ругаться будет по другому, то редактируешь /etc/lvm/archive/некий_бэкап.vg и вписываешь корректные девайсы (id девайса возможно тоже надо поправить, раз делал pvchange --uuid) и пробуешь его восстановить еще раз...

ЗЫ по проделанным действиям создается такое впечатление что тебе очень хотелось потерять свои данные...

----------

## fank

 *Quote:*   

> ЗЫ по проделанным действиям создается такое впечатление что тебе очень хотелось потерять свои данные...

 

вовсе нет

объясню подробнее

тот сервак нужно было быстро поднять из бэкапа

поэтому веники изначальные я достал, один из них подсоединил к своему компу и последние команды уже делаю на нем

 *Quote:*   

> ДО vgcfgrestore я сделал pvchange --uuid
> 
> а зачем? на какой девайс?

 

это сделано было для того, чтобы избавиться от сообщения об одинаковом PV id

ведь с самого начала мне нужно было восстановить этот, с позволения сказать, РЭЙД, для чего я подставил новый веник

недоРЭЙД продублировал данные побитно, поэтому PV id тоже стал одинаковым

lvm это не понравилось

 *Quote:*   

> какой? если тот на котором был рейд, то я не уверен насчет того где dmraid хранит метаданные, в начале или в конце диска...

 

к черту dmraid...

lvm, насколько я понял, просто аллокатит некий набор логических блоков (extent)

и держит инфу об этом у себя (в каком месте устройства???) в виде неких метаданных

поверх раздела lvm делается разметка ФС

нужно достать файлы - то есть узнать ГДЕ ИМЕННО начинается ФС

дальше - дело техники

в моих рассуждениях все правильно?

----------

## ba

 *fank wrote:*   

> lvm, насколько я понял, просто аллокатит некий набор логических блоков (extent)
> 
> и держит инфу об этом у себя (в каком месте устройства???) в виде неких метаданных
> 
> поверх раздела lvm делается разметка ФС
> ...

 

да, а это как раз продублировано в /etc/lvm/archive/некий_бэкап.vg, только надо учесть что есть ты убивал или ресайзил вольюмы, то данные могут ити не подряд, вобщем-то все должно быть записанов том файле бекапа

я бы правил этот файл и восстанавливался бы с него...

Забыл еще написать, что в бекап кладутся данные _перед_ последним изменением, соответсвенно если последним действием ты создавал тот вольюм который тебе надо восстановить, то его в бекапе нет, но есть комманда которой он создавался и можно попробовать создать его заново...

----------

## Santyaga

никогда, никогда, никогда fake raid.

лучше софт.

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

----------

## fank

 *Quote:*   

> да, а это как раз продублировано в /etc/lvm/archive/некий_бэкап.vg, только надо учесть что есть ты убивал или ресайзил вольюмы, то данные могут ити не подряд, вобщем-то все должно быть записанов том файле бекапа 
> 
> я бы правил этот файл и восстанавливался бы с него... 
> 
> Забыл еще написать, что в бекап кладутся данные _перед_ последним изменением, соответсвенно если последним действием ты создавал тот вольюм который тебе надо восстановить, то его в бекапе нет, но есть комманда которой он создавался и можно попробовать создать его заново...

 

система точно не ресайзилась

все делалось по словам того человека один единственный раз

ок, завтра буду уже искать инфу в том файле

всем большое спасибо!

надеюсь на дальнейшую помощь

----------

## fank

всем спасибо и отбой

восстановили инфу на ext3

помогла вот эта утилитка

----------

## fank

и напоследок все же хочу сказать о своих впечатлениях в процессе

как это обычно в линухе - хорошая, в общем-то идея, реализована через одно место

это касается как lvm2, так и ext3 (про другие говорить не буду, но по моим прикидкам ситуация не лучше)

потеря метаданных - вобщем не такой уж невероятный исход аппаратных проблем

их НУЖНО дублировать, причем в нормальном человечеком виде

я конечно сильно извиняюсь, но что касается NTFS - там я вообще себя спокойно чувствую

вручную восстанавливаю систему только в путь, сколько раз уже было

если лень копаться - testdisk, у которого полный арсенал сигнатур начала ФС, данных файла (.doc, .xls, etc.)

MFT продублирована и ПОНЯТНА даже человеку, вооруженному hex редактором

сам я обычно ставлю reiserfs, но кто даст гарантии, что мне не придется заниматься восстановлением обрушенной ФС?

где инструменты?

итог - очередной слив линуха против всеми-охаянной-МС

P.S. Возражения всячески приветствуются. Малоконкретные выкрики здесь не нужны, не позорьтесь.

----------

## Laitr Keiows

 *fank wrote:*   

> итог - очередной слив линуха против всеми-охаянной-МС

 

 *fank wrote:*   

> Ставился на полусофтовый RAID1, который на матери

 

Это "слив" полусофтового рейда на матери, линукс тут не при чем.

На будущее стоит не пользоваться этой поделкой, и стоит пользоваться встроенным в ядро RAID1.

У меня с ним неоднократно слетали диски и, после замены дисков, все восстанавливалось без проблем.

----------

## fank

 *Laitr Keiows wrote:*   

>  *fank wrote:*   итог - очередной слив линуха против всеми-охаянной-МС 
> 
>  *fank wrote:*   Ставился на полусофтовый RAID1, который на матери 
> 
> Это "слив" полусофтового рейда на матери, линукс тут не при чем.
> ...

 

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

я понимаю, что mdadm разрулит даже ситуацию с потерей метаданных на одном винте

но то, что даже в случае, когда неопытный человек сделал так (а ему ДАЛИ так сделать), а потом вытянуть метаданные LVM2 невозможно без полуночных плясок с бубном (а в случае ведения бизнеса 24/7 времени на это просто нет), явно говорит не в пользу линуха

к слову - оф разработчик утверждал, что вытянуть данные с ext3 в принципе практически невозможно

а потом я нахожу вот эту статью

как-то это все....

----------

## FlaTHunTeR

 *fank wrote:*   

> 
> 
> да, но тот факт, что данные были в данной конкретной ситуации восстановлены с помощью платного тула, который под win32, удручает....
> 
> я понимаю, что mdadm разрулит даже ситуацию с потерей метаданных на одном винте
> ...

 

Потому этот тул и платный! В жизни вообщем то, либо ты думаешь сам, либо ты платишь за чьи-то раздумия! 

В случае с таким бизнесом, как минимум "таких" неопытных людей не стоит подпускать к столь важным данным...

И как уже говорили вам, линух сдесь вовсе не при делах! Не стоит лить недовольствие за собственную некомпетентность на ось! Компьютер - лишь инструмент в руках человека!  :Wink: 

----------

## Laitr Keiows

 *fank wrote:*   

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

 

Потому что никто и никогда в здравой памяти не будет использовать fake raid под Linux, и именно потому что им никто не пользуется никто не написал соответствующих программ для восстановления.

Зачем кто-то будет писать программу которая не только ему самому, но и вообще кому бы то ни было не нужна?..

----------

## fank

пардон, восстановление данных - это что, такая редкая задача чтоль?

неважно в результате чего произошло повреждение ФС

важно, что под линухом вменяемых прог для таких ситуаций - 0.0

----------

## ArtSh

 *fank wrote:*   

> пардон, восстановление данных - это что, такая редкая задача чтоль?
> 
> неважно в результате чего произошло повреждение ФС
> 
> важно, что под линухом вменяемых прог для таких ситуаций - 0.0

 

Вы знаете, что существует вероятность повреждения ФС из-за разрушения поверхности диска, например в результате трагического стечения обстоятельств (например после короткого замыкания). Как Вы думаете, должны ли разработчики предусмотреть вариант на этот случай?

Недавно я по ошибке удалил большую часть distfiles. Раздел был на reiserfs. Там, конечно, есть инструменты для восстановления, но они практически не помогли, большая часть найденных файлов была повреждена. Я считаю, что такое "восстановление" не нужно.

----------

## Laitr Keiows

 *fank wrote:*   

> пардон, восстановление данных - это что, такая редкая задача чтоль?

 

О том и речь. Восстановление данных из fake raid под Linux именно такая редкая задача по причинам указанным мной выше.

----------

## fank

 *Quote:*   

> О том и речь. Восстановление данных из fake raid под Linux именно такая редкая задача по причинам указанным мной выше.

 

это частный случай (что касается причин)

насчет редкости задачи - я предлагаю погуглить вообще на предмет (знаю, я псих)

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

меня сильно удивляет подход к таким задачам оф разработчиков

по сути, несчастных просто бросают на произвол...

----------

## g-user

Согласен чертовски неприятно когда raid1 рушится в никуда. Кстати у вас была ситуация для которой от которой он собственно и должен был защитить. Вы знаете поэтому в хороших книгах по администрированию обязательно фигурирует некий "recovery plan" и даже рекомендуется после создания всех бэкапов в некритичное для конторы время проводить вариации на тему "а что будет если..."  к сожалению многие считают это лишним, а потом когда в реальной ситуации оказывается что бэкапы не актуальны, или появляются еще какие нибудь проблемы хватаются за голову. Я вас не в коей мере не виню, может быть на вас и без проблем по горло понавешали, к сожалению за многими конторами такое водится.

 *Quote:*   

>  восстановлены с помощью платного тула, который под win32, удручает.... 

 

Вы знаете я давно с удовольствием пользуюсь wininternals pack для восстанавления машин под виндой (бывают и такие  :Laughing:  ) и то что он в свое время стоил под несколько тысяч долларов меня не разу не удручало. 

 *Quote:*   

> невозможно без полуночных плясок с бубном (а в случае ведения бизнеса 24/7 времени на это просто нет),

 

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

 *Quote:*   

> явно говорит не в пользу линуха 

 

вы знаете в подобных случаях которых множество и на других ОС многие кричат тоже самое практически всегда, название ОС не столь важно. Ругают всех, и весьма нецензурно. Эмоции, адреналин и все такое. А ведь самое слабое звено по моему жизненному опыту - это во большинстве случаев человек. Я не в коей мере не хочу вас обидеть. 

 *Quote:*   

>  на один, который без этого рэйда, была поставлена собственно система 

 

 *Quote:*   

> после ребилда рэйда система грузится с нормального рабочего винта

 

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

 *Quote:*   

> VolGroup00\LogVolume01 --- это своп 

 

а зачем запихнули своп в LVM? В чем смысл этого действа? Впрочем это не столь важно.

 *Quote:*   

>  вытянуть метаданные LVM2 

 

Мне не очень понятны причины приведшие к подобной проблеме. Принимая за истину что fake-raid1 честно выполнил свои функции а именно продублировал информацию с диска 1 на диск 2, и собственно вернул все на исходную точку, я не понимаю почему возникла проблема с прочтением информации с VolGroup01\LogVolume03

Оставим эмоции - в чем же может быть дело? Жаль что на виртуальных машинках не получится, fake-raid еще не виртуализировали, а софтовый lvm это из другой серии. 

Статус [Slv] ставить рановато по моему.

----------

## Laitr Keiows

 *g-user wrote:*   

> Статус [Slv] ставить рановато по моему.

 

Вопрос был о восстановлении данных.

Данные были восстановлены.

Отсюда статус [Slv]

----------

