Назад | Перейти на главную страницу

Debian Lenny - SAN - сбой LVM

У меня есть сервер Lenny, на котором настроено SAN-соединение как единственный PV для VG с именем 'datavg'.

Вчера обновил бокс патчами Debian и дал перезагрузку.

После перезагрузки он не загрузился, сказав, что не может найти / dev / mapper / datavg-datalv.

Вот что я сделал:
- загрузился в режиме восстановления и прокомментировал монтирование в / etc / fstab
- перезагрузился в полнофункциональный режим. (точка монтирования / data, только postgresql не может запуститься)
- сделал vgdisplay, lvdisplay, pvdisplay, чтобы узнать, что случилось с группой томов. (datavg полностью отсутствовал)

После этого я заметил, что LUN виден из Linux и что также виден раздел LVM:

# ls -la /dev/mapper/mpath0*
brw-rw---- 1 root disk 254, 6 2009-11-23 15:48 /dev/mapper/mpath0
brw-rw---- 1 root disk 254, 7 2009-11-23 15:48 /dev/mapper/mpath0-part1


- Затем я попробовал pvscan, чтобы узнать, может ли он найти PV. К сожалению, он не обнаружил раздел как PV.
- Я запустил pvck для раздела, но не нашел ни одной метки:

# pvck /dev/mapper/mpath0-part1 
  Could not find LVM label on /dev/mapper/mpath0-part1


- Затем мне стало интересно, может быть, LUN пуст, поэтому я сделал dd первых нескольких МБ. Здесь я мог видеть заголовки LVM:

datavg {
id = "removed-hwEK-Pt9k-Kw4F7e"
seqno = 2
status = ["RESIZEABLE", "READ", "WRITE"]
extent_size = 8192
max_lv = 0
max_pv = 0

physical_volumes {

pv0 {
id = "removed-AfF1-2hHn-TslAdx"
device = "/dev/dm-7"

status = ["ALLOCATABLE"]
dev_size = 209712382
pe_start = 384
pe_count = 25599
}
}

logical_volumes {

datalv {
id = "removed-yUMd-RIHG-KWMP63"
status = ["READ", "WRITE", "VISIBLE"]
segment_count = 1

segment1 {
start_extent = 0
extent_count = 5120

type = "striped"
stripe_count = 1        # linear

stripes = [
"pv0", 0
]
}
}
}
}

Обратите внимание, что это было из раздела, где pvck не смог найти метку LVM!


- Решил записать на раздел новую метку LVM и восстановить параметры из файла резервной копии.

pvcreate --uuid removed-AfF1-2hHn-TslAdx --restorefile /etc/lvm/backup/datavg  /dev/mapper/mpath0-part1


- Затем я запустил vgcfgrestore -f / etc / lvm / backup / datavg datavg
- После этого появляется при выдаче пвскана.
- С помощью vgchange -ay datavg я активировал VG, и LV стал доступен.
- Когда я пытался смонтировать LV, он не нашел никакой файловой системы. Я пробовал восстановление несколькими способами, но безуспешно.
- После создания DD пораженного LV я попытался воссоздать суперблоки с

mkfs.ext3 -S /dev/datavg/backupdatalv


- но результат этого не может быть смонтирован:

# mount /dev/datavg/backupdatalv /mnt/
mount: Stale NFS file handle

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

Мои вопросы:
- Как может быть, что ярлык LVM пропадает после патчей и перезагрузки?
- Почему файловая система отсутствует после восстановления PV? (Неужели команда pvcreate уничтожила данные?)
- Можно ли восстановить файловую систему ext3 в LV?
- Что я мог сделать, чтобы предотвратить эту проблему?

Заранее спасибо, Гер.

Однажды я столкнулся с подобной проблемой. В нашем случае кто-то создал раздел для хранения PV, но когда они запустили команду pvcreate, они забыли указать раздел и вместо этого использовали все устройство. Система работала нормально до перезагрузки, когда LVM больше не мог найти PV.

Итак, в вашем случае, возможно ли, что кто-то запустил "pvcreate / dev / mapper / mpath0" во время создания, а не "pvcreate / dev / mapper / mpath0-part1"? Если это так, вам нужно удалить таблицу разделов с диска, содержащего PV.

На странице руководства pvcreate (8) для удаления таблицы разделов:

dd if = / dev / zero of = PhysicalVolume bs = 512 count = 1

Код LVM в ядре не распознает PV всего устройства, если на устройстве есть таблица разделов. Как только мы удалили таблицу разделов, PV был распознан, и мы снова смогли получить доступ к нашим данным.