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

Главная Форумы POWER Systems AIX/Hardware восстановлени группы томов

Просмотр 16 веток ответов
  • Автор
    Сообщения
    • #19709
      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 и что делать дальше?

    • #19710
      andrewk
      Участник

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

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

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

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

    • #19711
      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

    • #19712
      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

    • #19713
      Alex
      Участник

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

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

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

    • #19714
      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

    • #19715
      skl
      Участник

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

    • #19716
      andrewk
      Участник

      importvg

    • #19717
      andrewk
      Участник
    • #19718
      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

    • #19719
      andrewk
      Участник

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

    • #19720
      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

    • #19722
      skl
      Участник

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

    • #19723
      Alex
      Участник

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

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

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

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

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

    • #19724
      Alex
      Участник

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

    • #19726
      andrewk
      Участник

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

    • #19741
      skl
      Участник

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

Просмотр 16 веток ответов
  • Для ответа в этой теме необходимо авторизоваться.