Ubuntu 上的 LVM 分区中的 VG 中缺少 LV

Ubuntu 上的 LVM 分区中的 VG 中缺少 LV

断电后,Ubuntu 10.04 Server 硬盘无法启动。我尝试使用,boot-repair但找不到操作系统。

我运行了 gdisk 来验证 lvm 分区的位置以及它是否仍然完好无损。输出如下:

GPT fdisk (gdisk) version 0.6.14

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): p
Disk /dev/sdb: 3907029168 sectors, 1.8 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 3A0E99EE-74F9-41F5-81A0-7B7D7235DE8E
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 3907029134
Partitions will be aligned on 2048-sector boundaries
Total free space is 2157 sectors (1.1 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048            4095   1024.0 KiB  EF02  
   2            4096          503807   244.0 MiB   EF00  
   3          503808      3907028991   1.8 TiB     8E00  

Command (? for help): i
Partition number (1-3): 3
Partition GUID code: E6D6D379-F507-44C2-A23C-238F2A3DF928 (Linux LVM)
Partition unique GUID: 4F35492A-C6DD-4E31-9D53-8C88A74A1B48
First sector: 503808 (at 246.0 MiB)
Last sector: 3907028991 (at 1.8 TiB)
Partition size: 3906525184 sectors (1.8 TiB)
Attribute flags: 0000000000000000
Partition name: 

所以,它仍然在那里,而且显然完好无损,所以我继续做 vgscan:

:/# vgscan

Reading all physical volumes. This may take a while... Found volume group "ubuntu" using metadata type lvm2

所以我做了:/# vgchange -ay ubuntu其次是:/# lvs并得到:

LV     VG     Attr   LSize   Origin Snap%  Move Log Copy%  Convert

root   ubuntu -wi-ao   4.40g

swap_1 ubuntu -wi-a- 260.00m  

问题是,其中应该有另一个大小接近 1.8TB 的 VG,但它没有显示。

那么.. 有什么方法可以恢复未显示在 lvs 中的 LV?我需要恢复上次备份后创建的 1 个重要文件。

:/# vgdisplay

  --- Volume group ---
  VG Name               ubuntu
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  3
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                2
  Open LV               0
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               1.82 TiB
  PE Size               4.00 MiB
  Total PE              476870
  Alloc PE / Size       1191 / 4.65 GiB
  Free  PE / Size       475679 / 1.81 TiB
  VG UUID               r3Z9Io-bWk7-i7wp-9QGZ-mF3o-ucQs-SdsaGW

答案1

我不清楚您现在丢失的是单个 1.8TB LV 还是 1.8TB PV + VG + LV。如果 LV 位于不同的 VG 中,那么最好尝试从 pvscan 开始查找丢失的磁盘。例如,您可能只是遇到了 lvm 过滤器或缓存问题。许多发行版试图通过将 lvm.conf 添加到 initrd 来让您大受困扰,但没有告诉您如果稍后更改它,则需要重建它。您可以运行 pvscan -vvv 并查看它是否显示有关“被过滤忽略”的任何信息。

如果您刚刚从配置中丢失了 LV,那么问题就是这怎么发生的以及它是否仍然可读。因此,从磁盘到 /dev/null 的测试 dd 可能是一个很好的起点,即看看您是否可以读取“旧 LV 所在的回旋处”

通常情况下,我会先在 fstab 中注释掉受影响的 LV,让系统再次成功启动。

作为最后的手段,您可以在磁盘上找到最新的 LVM 配置备份。可以使用类似 dd + strings + grep -A1000 "LVM" 的命令来读取它。但您还没有迷失方向 :) 根据该配置,可以将 LVM 配置的旧状态重新创建到磁盘。但在执行此操作之前,您必须清楚损坏的内容,我会在受影响磁盘的副本上测试整个内容,而不是在原始磁盘上。

相关内容