Каким образом можно восстановить файловую систему ext4, находящуюся на физическом томе LVM? 

После перезагрузки виртуальной машины возникли проблемы с файловой системой на LVM-диске, который был ранее расширен в ESXi. Теперь LVM-раздел воспринимается как физический раздел, и его информацию можно увидеть следующим образом: 
<pre><code>/dev/mapper/vg1-lv1: LVM2 PV (Linux Logical Volume Manager), UUID: sjXlXa-Ma5C-BT14-n0Na-69VR-BGzK-eIo7DW, size: 107372085248</code></pre> 
При попытке использовать команды 
<pre><code>e2fsck
fsck.ext4</code></pre> 
возникает ошибка, которая показывает следующее: 
<pre><code>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 &lt;device&gt;</code></pre> 
Теперь, чтобы объяснить предшествующие действия, отмечу, что до вмешательства в fdisk физический диск отображался следующим образом: 
<pre><code>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</code></pre> 
Хотя на самом деле на нем было LVM. Я понимаю, что необходимо было выбрать тип "8e" (LVM Linux), однако ранее система функционировала корректно с установленным типом.
  • 9 апреля 2025 г. 21:55
Ответы на вопрос 2 
Восстановление файловой системы ext4, находящейся на физическом томе LVM, может быть сложным процессом, особенно если произошли изменения в структуре разделов. Ситуация, которую вы описываете, подразумевает, что информация о типе раздела была изменена, что привело к нераспознаванию файловой системы.

Вот шаги, которые могут помочь восстановить доступ к вашей файловой системе:

### 1. Проверка структуры LVM

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

```bash
lvscan
```

Эта команда должна отобразить ваши логические тома. Если они отображаются как "inactive", их можно активировать командой:

```bash
lvchange -ay /dev/vg1/lv1
```

### 2. Проверка доступного пространства и состояния физического тома

Также проверьте состояние физических томов LVM:

```bash
pvscan
```

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

### 3. Попытка проверки файловой системы с помощью альтернативных суперблоков

Если ваша файловая система ext4 действительно повреждена, проверьте альтернативные суперблоки. Если «e2fsck» не может получить доступ к файловой системе, попробуйте выполнить команду с указанием альтернативного суперблока:

```bash
e2fsck -b 32768 /dev/vg1/lv1
```

Обычные местоположения для альтернативных суперблоков:
- 8193
- 32768
- 98304
- 163840
- 229376

### 4. Использование rescue или live-системы

Если указанные выше шаги не помогли, загрузитесь с LiveCD или USB-накопителя, содержащего утилиты для работы с ext4 (например, SystemRescueCD). Это может помочь избежать проблем в случае, если LVM или файловая система находятся в активном использовании.

### 5. Восстановление данных

Если ни одно из решений не сработает, возможно, вам придется рассмотреть возможность использования инструмента восстановления данных, такого как `testdisk` или `photorec`, чтобы попытаться восстановить данные.

### 6. Обращение к профессионалам

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

### Дополнительные советы:
- Всегда создавайте резервные копии данных перед выполнением операций, которые могут нарушить файловую систему.
- Никаких операций с `fdisk` или изменениями типа разделов, если вы не уверены в том, что делаете. Это может серьезно нарушить доступность данных.
С горем пополам пофиксил сам: 
 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
Похожие вопросы
    Показать ещё