更新

Question

这里存在同样的问题，使用某种有点黑客的方式解决了dd。

我们有三年前在 LVM 上设置了 root。现在其中一个物理磁盘彻底失效了：

pier41:~# hdparm -I /dev/sdb
/dev/sdb:
 HDIO_DRIVE_CMD(identify) failed: Input/output error

有一个LVM镜像恢复说明内容如下：

对镜像卷的任何写入活动都会导致 LVM 检测到镜像故障。发生这种情况时，LVM 会将镜像转换为单个线性卷。

不幸的是，这个说法似乎是错误的，至少对于我们的 Debian 10 Buster 内核版本 4.19 来说是这样。自动转换没有发生，/dev/vg0/root仍然是镜像。由于内核页面缓存，从卷中读取某些文件是可行的，读取其他一些文件会导致 I/O 错误。我能够保存/etc/lvm/lvm.conf 并/etc/lvm/backup/vg0。最后系统无法使用，不得不艰难地重新启动echo b > /proc/sysrq-trigger。

我已经在另一台机器上准备好了替换磁盘：

# fdisk /dev/sdX
# pvcreate --uuid [for sdb2 in ./lvm.conf] --restorefile backup/vg0 /dev/sdX2

用替换磁盘替换故障磁盘并尝试启动 - 没有成功，无法挂载根。好的，从救援闪存启动。

pier41:~# lvdisplay -m /dev/vg0/root
  --- Logical volume ---
  LV Path                /dev/vg0/root
  LV Name                root
  VG Name                vg0
  LV UUID                xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
  LV Write Access        read/write
  LV Creation host, time pier41, 2019-01-21 15:25:14 +0300
  LV Status              NOT available
  LV Size                <20.29 GiB
  Current LE             5194
  Mirrored volumes       2
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto

  --- Segments ---
  Logical extents 0 to 5193:
    Type                raid1
    Monitoring
    Raid Data LV 0
      Logical volume    root_rimage_0
      Logical extents   0 to 5193
    Raid Data LV 1
      Logical volume    root_rimage_1
      Logical extents   0 to 5193
    Raid Metadata LV 0  root_rmeta_0
    Raid Metadata LV 1  root_rmeta_1

其他（非镜像）LV 都有LV Status available。从镜像 LV 转换 /dev/vg0/root为普通 LV 确实不起作用：

# lvconvert -m0 /dev/vg0/root
  vg0/root must be active to perform this operation
# lvchange -ay --activationmode degraded /dev/vg0/root
  device-mapper: reload ioctl on (253:122) failed: Invalid argument

但是我们可以使用报告的映射手动lvdisplay -m从健康的底层 PV（/dev/sda2）复制数据。创建一个新的 LV/dev/vg0/root3来将数据复制到：

# lvcreate -n root3 -l 5194 vg0 /dev/sdb3

我们明确指定目标 PV（/dev/sdb3），以免 LVM 尝试在故障 PV 上创建 LV。

PV 的结构很简单：它以元数据区域开始，然后是从 0 开始编号的大量 PE 数组。我们可以使用找到 PE 大小，pvdisplay并使用找到到 PE_0 的偏移量pvck：

pier41:~# pvdisplay /dev/sda2 | grep 'PE Size'
  PE Size               4.00 MiB
pier41:~# pvck /dev/sda2
  Found label on /dev/sda2, sector 1, type=LVM2 001
  Found text metadata area: offset=4096, size=1044480
pier41:~> expr 4096 + 1044480
1048576

1048576字节的偏移量正好是2^20 = 1MiB，所以我们可以方便地按1MiBdd块进行操作：

# dd < /dev/sdb2 > /dev/vg0/root3 bs=1M skip=1 count=20776

其中 20776=5194*4 是rootLV 大小（以 1MiB 块为单位）。鉴于只有这一个段需要复制，我们也可以省略count=，直接复制至/dev/vg0/root3满为止。

完成后dd，确认我们复制的数据确实是一个文件系统：

# fsck /dev/vg0/root3

此时我已经使用/etc/lvm从恢复的root3LV 完成替换磁盘上的元数据重建：

# mount /dev/vg0/root3 /mnt
# vgcfgrestore --file /mnt/etc/lvm/backup/vg0 vg0
# umount /mnt

最后，我重命名了 LV 以便从恢复的 LV 启动：

# lvrename vg0 root rootfail
# lvrename vg0 root3 root
# reboot

现在系统启动正常了。下一步是恢复所有非镜像 LV 中的数据，由于与问题无关，因此省略。

更新

在重新创建镜像设置时，我发现了一个更简单的解决方案：大胆删除“不可用”的镜像 LV，然后在健康 PV 上的同一位置重新创建线性 LV：

pier41:~# lvremove /dev/vg0/rootfail
  Logical volume "rootfail" successfully removed
pier41:~# lvcreate -Zn -Wn -n root4 -l 5194 vg0 /dev/sda2:0-5193
  WARNING: Logical volume vg0/root4 not zeroed.
  Logical volume "root4" created.
pier41:~# fsck /dev/vg0/root4
(journal replay, minor corrections, OK)

选项-Zn和-Wn禁用清零 LV 的前 4KB 以及文件系统签名检测和擦除（lvcreate通常会这样做）（请参阅man lvcreate）。如果您忘记了它们，fsck会抱怨很多，但无论如何都会应付，不会丢失任何文件。

此解决方案不需要额外的空间（root3）来复制文件系统。

Answer 1