восстановлени группы томов

[skl]

Описание ситуации:
железо р520, СХД DS 4300, ОС AIX 5.3
начала сбоить одна из файловых систем. После перезагрузки соответствующая группа томов стала неактивна. varyonvg не прошло, export/import тоже. после этого:

#importvg -f -y datavg hdisk12
PV Status: hdisk12 00c6638df8458874 PVACTIVE
hdisk13 0000000000000000 INVPVID
hdisk14 0000000000000000 DUPPVID
00c6638de7536cb2 NONAME
00c6638d0f4ca4e6 NONAME
varyonvg: Volume group datavg is varied on.
datavg
PV Status: hdisk12 00c6638df8458874 PVACTIVE
hdisk13 0000000000000000 INVPVID
hdisk14 0000000000000000 DUPPVID
00c6638de7536cb2 NONAME
00c6638d0f4ca4e6 NONAME
varyonvg: Volume group datavg is varied on.
#lsvg
datavg
rootvg
homevg
oraclevg
#lspv
hdisk0 00c6638de289ee96 rootvg active
hdisk1 00c6638de3b8aba6 rootvg active
hdisk10 00c6638df844e194 homevg active
hdisk11 00c6638df8453b9f oraclevg active
hdisk12 00c6638df8458874 datavg active
hdisk13 00c6638de7536cb2 datavg active
hdisk14 00c6638d0f4ca4e6 datavg active

#mount /f3
Replaying log for /dev/fslv03.
Fatal: I/O error
mount: 0506-324 Cannot mount /dev/fslv03 on /f3: The media is not formatted or the format is not correct.
0506-342 The superblock on /dev/fslv03 is dirty. Run a full fsck to fix.

#fsck /dev/fslv03

The current volume is: /dev/fslv03
Primary superblock is valid.
J2_LOGREDO:log redo processing for /dev/fslv03
Fatal: I/O error
exec module “/sbin/helpers/jfs2/logredo64” failed.
logredo failed (rc=5). fsck continuing.
Primary superblock is valid.
*** Phase 1 – Initial inode scan
Fatal: I/O error
#varyoffvg datavg
#exportvg datavg

После этого диски были удалены, запущен cfgmgr (теперь они hdisk2,3,4)
#lspv
hdisk0 00c6638de289ee96 rootvg active
hdisk1 00c6638de3b8aba6 rootvg active
hdisk2 00c6638df8458874 None
hdisk3 none None
hdisk4 none None
hdisk10 00c6638df844e194 homevg active
hdisk11 00c6638df8453b9f oraclevg active

вопрос: можно ли восстановить datavg и что делать дальше?

[andrewk]

можно. из последнего бэкапа.

на самом деле все зависит от того, сохранились ли данные на этих двух дисках. Если сохранились – то можно восстановить pvid и все заново смонтировать. Быстрее будет восстановить из бэкапа, чем мы Вам тут поможем.

Для начала пришлите вывод:
1. lsdev -l hdisk*
2. lscfg -vl hdisk*
3. fget_config -Av

И проверьте лог ошибок на сторедже.

[skl]

бекапа нет, на сторадже ошибок нет

#lsdev -l hdisk*
hdisk0 Available 09-08-00-5,0 16 Bit LVD SCSI Disk Drive
hdisk1 Available 09-08-00-8,0 16 Bit LVD SCSI Disk Drive
hdisk2 Available 0B-08-01 1722-600 (600) Disk Array Device
hdisk3 Available 0B-08-01 1722-600 (600) Disk Array Device
hdisk4 Available 0B-08-01 1722-600 (600) Disk Array Device
hdisk10 Available 0B-08-01 1722-600 (600) Disk Array Device
hdisk11 Available 0B-08-01 1722-600 (600) Disk Array Device

#lscfg -vl hdisk*
hdisk0 U787A.001.DPM02WZ-P1-T10-L5-L0 16 Bit LVD SCSI Disk Drive (73400 MB)

Manufacturer…………….IBM
Machine Type and Model……HUS103073FL3800
FRU Number………………00P3833
ROS Level and ID…………52505146
Serial Number……………004498EB
EC Level………………..00000Q1A10
Part Number……………..26K5191
Device Specific.(Z0)……..000004129F00013E
Device Specific.(Z1)……..RPQF
Device Specific.(Z2)……..0068
Device Specific.(Z3)……..05094
Device Specific.(Z4)……..0001
Device Specific.(Z5)……..22
Device Specific.(Z6)……..00000Q1A10

hdisk1 U787A.001.DPM02WZ-P1-T10-L8-L0 16 Bit LVD SCSI Disk Drive (73400 MB)

Manufacturer…………….IBM
Machine Type and Model……HUS103073FL3800
FRU Number………………00P3833
ROS Level and ID…………52505146
Serial Number……………0041540A
EC Level………………..00000Q1A10
Part Number……………..26K5191
Device Specific.(Z0)……..000004129F00013E
Device Specific.(Z1)……..RPQF
Device Specific.(Z2)……..0068
Device Specific.(Z3)……..05094
Device Specific.(Z4)……..0001
Device Specific.(Z5)……..22
Device Specific.(Z6)……..00000Q1A10

hdisk2 U787A.001.DPM02WZ-P1-C4-T1-W200900A0B8178FF5-L2000000000000 1722-600 (600) Disk Array Device
hdisk3 U787A.001.DPM02WZ-P1-C4-T1-W200900A0B8178FF5-L3000000000000 1722-600 (600) Disk Array Device
hdisk4 U787A.001.DPM02WZ-P1-C4-T1-W200900A0B8178FF5-L4000000000000 1722-600 (600) Disk Array Device
hdisk10 U787A.001.DPM02WZ-P1-C4-T1-W200900A0B8178FF5-L0 1722-600 (600) Disk Array Device
hdisk11 U787A.001.DPM02WZ-P1-C4-T1-W200900A0B8178FF5-L1000000000000 1722-600 (600) Disk Array Device

#fget_config -Av

—dar0—

User array name = ‘DS4300_AIX_Uvengo’
dac0 ACTIVE dac2 ACTIVE

Disk DAC LUN Logical Drive
utm 31
hdisk2 dac2 2 DATA
hdisk3 dac2 3 DATA2
hdisk4 dac2 4 DATA3
hdisk10 dac2 0 Home
hdisk11 dac2 1 ORACLE

и вот ещё:
#lqueryvg -p hdisk2 -At
0516-320 lqueryvg: Physical volume hdisk2 is not assigned to
a volume group.
Max LVs: 256
PP Size: 28
Free PPs: 1
LV count: 2
PV count: 3
Total VGDAs: 2
Conc Allowed: 0
MAX PPs per PV 32768
MAX PVs: 1024
Quorum (disk): 1
Quorum (dd): 1
Auto Varyon ?: 2
Conc Autovaryo 0
Varied on Conc 0
Logical: 00c6638d00004c0000000117f8458aa4.1 loglv02 1
00c6638d00004c0000000117f8458aa4.2 fslv03 1
Physical: 00c6638df8458874 2 0
00c6638de7536cb2 0 4
00c6638d0f4ca4e6 0 4
Total PPs: 3515
LTG size: 128
HOT SPARE: 0
AUTO SYNC: 0
VG PERMISSION: 0
SNAPSHOT VG: 0
IS_PRIMARY VG: 0
PSNFSTPP: 7168
VARYON MODE: ???????
VG Type: 2
Max PPs: 32768

#lqueryvg -p hdisk3 -At
0516-304 lqueryvg: Unable to find device id hdisk3 in the Device
Configuration Database.
Max LVs: 256
PP Size: 28
Free PPs: 1
LV count: 2
PV count: 3
Total VGDAs: 3
Conc Allowed: 0
MAX PPs per PV 32768
MAX PVs: 1024
Quorum (disk): 1
Quorum (dd): 1
Auto Varyon ?: 2
Conc Autovaryo 0
Varied on Conc 0
Logical: 00c6638d00004c0000000117f8458aa4.1 loglv02 1
00c6638d00004c0000000117f8458aa4.2 fslv03 1
Physical: 00c6638df8458874 1 0
00c6638de7536cb2 1 0
00c6638d0f4ca4e6 1 0
Total PPs: 3515
LTG size: 128
HOT SPARE: 0
AUTO SYNC: 0
VG PERMISSION: 0
SNAPSHOT VG: 0
IS_PRIMARY VG: 0
PSNFSTPP: 7168
VARYON MODE: ???????
VG Type: 2
Max PPs: 32768

#lqueryvg -p hdisk4 -At
0516-304 lqueryvg: Unable to find device id hdisk4 in the Device
Configuration Database.
Max LVs: 256
PP Size: 28
Free PPs: 1
LV count: 2
PV count: 3
Total VGDAs: 3
Conc Allowed: 0
MAX PPs per PV 32768
MAX PVs: 1024
Quorum (disk): 1
Quorum (dd): 1
Auto Varyon ?: 2
Conc Autovaryo 0
Varied on Conc 0
Logical: 00c6638d00004c0000000117f8458aa4.1 loglv02 1
00c6638d00004c0000000117f8458aa4.2 fslv03 1
Physical: 00c6638df8458874 1 0
00c6638de7536cb2 1 0
00c6638d0f4ca4e6 1 0
Total PPs: 3515
LTG size: 128
HOT SPARE: 0
AUTO SYNC: 0
VG PERMISSION: 0
SNAPSHOT VG: 0
IS_PRIMARY VG: 0
PSNFSTPP: 7168
VARYON MODE: ???????
VG Type: 2
Max PPs: 32768

#lqueryvg -Ptp hdisk2
Physical: 00c6638df8458874 2 0
00c6638de7536cb2 0 4
00c6638d0f4ca4e6 0 4
#lqueryvg -Ptp hdisk3
Physical: 00c6638df8458874 1 0
00c6638de7536cb2 1 0
00c6638d0f4ca4e6 1 0
#lqueryvg -Ptp hdisk4
Physical: 00c6638df8458874 1 0
00c6638de7536cb2 1 0
00c6638d0f4ca4e6 1 0

[andrewk]

ну если lqueryvg что-то выдает, то можно попробовать и рискнуть. для очистки совести еще попробуйте readvgda запустить – если там есть “нормальная” VGDA, то есть шанс, что и данные в порядке.

https://www.ibm.com/developerworks/community/blogs/mehdi/entry/how_to_set_the_pvid_of_a_disk_to_a_specific_value21?lang=en

[Alex]

Подозреваю, что шанс на спасение ничтожен.

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

Сомнительно, что развалилось само. Уже на момент importvg из лога видно, что на двух дисках (hdisk13, hdisk14) как минимум отсутствует pvid. Вряд ли кто-то затёр его точечно, а значит там уже ничего нет. Логи массива дадут ответ.

[skl]

pvid восстановлены, VGDA есть на всех дисках, что дальше?
#lspv
hdisk0 00c6638de289ee96 rootvg active
hdisk1 00c6638de3b8aba6 rootvg active
hdisk2 00c6638df8458874 None
hdisk3 00c6638de7536cb2 None
hdisk4 00c6638d0f4ca4e6 None
hdisk10 00c6638df844e194 homevg active
hdisk11 00c6638df8453b9f oraclevg active

[skl]

в логах массива на момент сбоя вообще ничего нет. сбой в работе файловой системы произошел в момент когда I/O на диске достигали 100%. такое впечатление что LVM глюканул.

[andrewk]

importvg

[andrewk]

http://www-01.ibm.com/support/docview.wss?uid=isg1IZ00760

[skl]

так что, importvg -y …
меня смущает вот это:
#lqueryvg -Ptp hdisk4
Physical: 00c6638df8458874 1 0
00c6638de7536cb2 1 0
00c6638d0f4ca4e6 1 0
#lqueryvg -Ptp hdisk3
Physical: 00c6638df8458874 1 0
00c6638de7536cb2 1 0
00c6638d0f4ca4e6 1 0
#lqueryvg -Ptp hdisk2
Physical: 00c6638df8458874 2 0
00c6638de7536cb2 0 4
00c6638d0f4ca4e6 0 4

[andrewk]

Вы попробуйте импортировать с одного из дисков. Если не получится – с другого. hdisk2 считает, что все VGDA находят только на нем, а hdisk3 и hdisk4 с ним не согласны. Вам по большому счету все равно, где находятся VGDA, главное, чтобы их было 2 штуки и они были одинаковыми. Учитывая, что Вы уже вроде пытались делать importvg с hdisk2, который был hdisk12, то попробуйте сейчас импортировать сначала с hdisk3, например.

[skl]

результат таков:
#importvg -y datavg hdisk3
PV Status: hdisk2 00c6638df8458874 PVACTIVE
hdisk3 00c6638de7536cb2 PVREMOVED
hdisk4 00c6638d0f4ca4e6 PVREMOVED
varyonvg: Volume group datavg is varied on.
datavg
PV Status: hdisk2 00c6638df8458874 PVACTIVE
hdisk3 00c6638de7536cb2 PVREMOVED
hdisk4 00c6638d0f4ca4e6 PVREMOVED
varyonvg: Volume group datavg is varied on.

#lsvg -p datavg
datavg:
PV_NAME PV STATE TOTAL PPs FREE PPs FREE DISTRIBUTION
hdisk2 active 1799 0 00..00..00..00..00
hdisk3 removed 359 0 00..00..00..00..00
hdisk4 removed 1357 1 00..00..00..00..01

[skl]

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

[Alex]

Теперь ещё ближе к тому, что я предположил. Данные выжили только на hdisk2, а с hdisk[34] случилось нечто, после чего данные там перестали существовать. VGDA на этих дисках появилась после первого форсированного importvg.

Если злоумшленника нет и массив это устроил сам под нагрузкой, – даже я, как ярый ненавистник перелицованного LSI, известного там как серия DS4xxx у IBM, шокирован.

Да, это, случайно, не одно из плечей HACMP-кластера?

Update: О! Я за вас честно рад и хорошо, что мои прогнозы не оправдались 😉 Нечасто такие события заканчиваются настолько безболезненно.

Не понял только, у вас после importvg система двух дисков не нашла – вы их как запихнули в VG? Удалили и cfgmgr?

[Alex]

4andrewk: баг с нечитаемостью pvid, конечно, фееричен не меньше, чем его решение .-)

[andrewk]

asddsa, это на самом деле то, что я нашел на быструю руку. но если мне не изменяет память, в AIX 5.3 были еще несколько багов в LVM, результатом которых было стирание PVID.

[skl]

да, диски удалили и после cfgmgr у 2-х из 3-х, входивших в группу томов, отсутствовал pvid. pvid удалось прописать руководсвуясь ссылкой предоставленной andrewk. данные на дисках сохранились. приложение работает.
резюмируя можно сказать, что видимо, причиной инцидента послужило разрушение vg в результате потери pvid 2-я её дисками.
кстати, fix по ссылке andrewk в системе установлен. видимо andrewk прав и есть ещё баги.

[Автор]

Сообщения