Как исправить файловую систему ext4 на LVM?

Question

[Антон Пащенко]

После перезагрузки Виртуальной Машины слетела файловая система на LVM диске, который до этого был расширен в ESXi.
Сейчас ситуация с LVM разделом следующая, его ФС определяется как будто он физический раздел с LVM:

/dev/mapper/vg1-lv1: LVM2 PV (Linux Logical Volume Manager), UUID: sjXlXa-Ma5C-BT14-n0Na-69VR-BGzK-eIo7DW, size: 107372085248

Соответственно команды

e2fsck
fsck.ext4

выдают одинаковый результат:

e2fsck 1.42.9 (28-Dec-2013)
ext2fs_open2: Bad magic number in super-block
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/mapper/vg1-lv1

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

Перед тем как описать анамнез, спойлерну. До манипуляций в fdisk физический диск выглядел так:

Disk /dev/sdb: 107.4 GB, 107374182400 bytes, 209715200 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: gpt
Disk identifier: 6446AAF3-C422-41BC-885A-5B7D038E4918
#         Start          End    Size  Type            Name
 1         2048    209713151    100G  Microsoft basic

По факту на нём был LVM, знаю, что тип надо было выбрать "8e" он же LVM Linux, но было так и работал на нём LVM:

pvs
  PV         VG  Fmt  Attr PSize    PFree
  /dev/sdb1  vg1 lvm2 a--  <100.00g    0
vgs
 VG  #PV #LV #SN Attr   VSize    VFree
  vg1   1   1   0 wz--n- <100.00g    0
lvs
  LV   VG  Attr       LSize    Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  lv1  vg1 -wi-ao---- <100.00g

Ну и на самом LVM была файловая система EXT4:

file -sL /dev/mapper/vg1-lv1
/dev/mapper/vg1-lv1: Linux rev 1.0 ext4 filesystem data, UUID=191c9180-f8c4-4cab-a3ae-4099e9a424c0, volume name "bxData" (needs journal recovery) (extents) (64bit) (large files) (huge files)

Теперь анамнез:
1. Увеличен размер диска в ESXi (не добавлен ещё один, а увеличен существующий).
2. Пересканирован диск в гостевой ОС:

echo '1' > /sys/class/scsi_disk/2\:0\:1\:0/device/rescan

3. Создан доп. раздел /dev/sdb2 через fdisk
4. Ну и дальше по классике:

pvcreate /dev/sdb2
vgextend vg1 /dev/sdb2
lvresize -l +100%FREE /dev/vg1/lv1
partprobe
resize2fs /dev/mapper/vg1-lv1

На выходе всё было ровно, диск увеличился с 100Гб до 120Гб, без перезагрузки ВМ, целых 18 дней на него писались данные и читались без проблем. Но на 18й день вырубился свет, никто ни о чём не сообщил и через 20мин сдох ИБП и вырубился сервер. (Да, ИБП простой без USB или RS-232).
А после загрузки имеем:
1. Не смонтированный диск.
2. На первом разделе с какого-то перепуга начальный сектор сместился с 2048го на 1й

Disk /dev/sdb: 128.8 GB, 128849018880 bytes, 251658240 sectors
   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1   209715199   104857599+  8e  Linux LVM
/dev/sdb2       209715200   251658239    20971520   8e  Linux LVM

3. LVM вместо EXT4 показывает " LVM Linux", будто он физический диск:

file -sL /dev/mapper/vg1-lv1
/dev/mapper/vg1-lv1: LVM2 PV (Linux Logical Volume Manager), UUID: sjXlXa-Ma5C-BT14-n0Na-69VR-BGzK-eIo7DW, size: 107372085248

да ещё и UUID показывает от /dev/sdb1

file -sL /dev/sdb1
/dev/sdb1: LVM2 PV (Linux Logical Volume Manager), UUID: sjXlXa-Ma5C-BT14-n0Na-69VR-BGzK-eIo7DW, size: 107372085248

было так:

file -sL /dev/mapper/vg1-lv1
/dev/mapper/vg1-lv1: Linux rev 1.0 ext4 filesystem data, UUID=191c9180-f8c4-4cab-a3ae-4099e9a424c0, volume name "bxData" (needs journal recovery) (extents) (64bit) (large files) (huge files)

Parted показывает следующее:
Было:

Model: VMware Virtual disk (scsi)
Disk /dev/sdb: 107GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End    Size   File system  Name  Flags
 1      1049kB  107GB  107GB

Стало:

Model: VMware Virtual disk (scsi)
Disk /dev/sdb: 129GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start  End    Size    Type     File system  Flags
 1      512B   107GB  107GB   primary               lvm
 2      107GB  129GB  21.5GB  primary               lvm

Ну и естественно не монтируется и не фиксится.

Целый день гуглил, в итоге что более менее смог понять, что фактически произошло смещение данный на диске "назад" с 2048 сектора на 1й, поэтому и всё проблемы.

Сейчас этот диск откачен на дату до манипуляций описанных выше, потери данных составили 1Гб всяких рабочих файлов в количестве 473шт.

Параллельно развёрнута ВМ с диском "до манипуляций" и последняя версия "до перезагрузки", которая стала непригодной.

Прошу помощи, как правильно действовать, в какие программы лучше использовать, чтобы сместить обратно данные диска, восстановить ФС и вытащить данные.
Как вариант можно применить план минимум, просто вытянуть файлы и в общем то всё...

Comments

[rPman]

не могу понять, как отключение света могло порушить структуру lvm
отключение происходило в момент манипуляций?

еще момент. в виртуальной машине можно включать кеширование записей на диски, не помню про vmware но это фича всех виртуалок, обычно про это предупреждают сразу, что все может стать плохо но поднимает скорость работы с диском (записи) очень заметно

[Alexey Dmitriev]

На будущее, в пакете cloud-utils есть утилита growpart, которая позволяет упростить расширение разделов.

[Антон Пащенко]

Alexey Dmitriev, спасибо! Обязательно изучу!

[Антон Пащенко]

rPman, кеширования не было.
У меня после всех разборов полетов закралось подозоение, что я когда первый раз после расширения диска полез вв fdisk, я решил пересоздать и первый раздел, чтобы сделать его LVM, и похоже на вопрос fdisk о номере начального сектора ответил цифрой "1", думая, что отвечаю на вопрос о номере раздела. А дальше т. к. я LVM не перемонтировал, он и работал до ближайшего перемонтирования, которое случилось при перезагрузке.
Скорее всего так и было.

Answer 1

[Антон Пащенко]

С горем пополам пофиксил сам:
1. Удалил разделы с /dev/sdb
2. Создал заново разделы на /dev/sdb, установив начало первого на 2048й сектор, конечный сектор первого диска подсмотрел на рабочей ВМ с диском откаченным из бэкапа.
3. Столкнулся с проблемой PV [unknown] на месте /dev/sdb2, решил так:

pvcreate --uuid "тут UUID того PV который [unknown]" --restorefile /etc/lvm/archive/{тут файл архива .vg который бал на момент изначального расширения +20Гб моей VG} /dev/sdb2

затем
vgcfgrestore vg1
4. Ещё момент vgdisplay показывал что у него из 2х PV активный только 1, вылечило от этого повторное добавление потерянного PV в VG

vgextend /dev/sdb2 vg1
vgcfgrestore -f /etc/lvm/archive/{тут файл архива .vg который бал на момент изначального расширения +20Гб моей VG} vg1

5.

systemctl daemon-reload
partprobe

и всё взлетело!

/dev/mapper/vg1-lv1  118G   87G   26G  77% /home/bitrix/www/upload

pvdisplay
File descriptor 7 (pipe:[27112]) leaked on pvdisplay invocation. Parent PID 8769: bash
  --- Physical volume ---
  PV Name               /dev/sdb1
  VG Name               vg1
  PV Size               <100.00 GiB / not usable 2.00 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              25599
  Free PE               0
  Allocated PE          25599
  PV UUID               sjXlXa-Ma5C-BT14-n0Na-69VR-BGzK-eIo7DW

  --- Physical volume ---
  PV Name               /dev/sdb2
  VG Name               vg1
  PV Size               20.00 GiB / not usable 4.00 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              5119
  Free PE               0
  Allocated PE          5119
  PV UUID               vBNMOq-iIQD-0H1B-nosS-iWmt-wzKm-IMslD6

Comments

[ky0]

Ждите следующего отключения электричества. Вы явно не понимаете, что делаете.

[Антон Пащенко]

ky0, Здравствуйте!
Понятно, что не понимаю, потому тут и пишу вопрос.
Объясните, пожалуйста, что не так?
П.с.: кстати, следующего можно не бояться, т.к. я это сделал на копии скачал файлы и всё. А на боевом портале, просто добавил винт в ESXi, а потом в LVM, а не расширил как в прошлый раз.