☰

更新1

tag-icon • tag-icon lvm data-recovery mdadm raid1
更新1

我正在尝试从发生故障的旧 NAS 驱动器恢复数据。我不确定失败的原因，但驱动器上的文件相对完整，而且我过去已经能够使用一些非常笨重的 debugfs 方法来完成一些工作。我再次关注这个问题，希望能以正确和正确的方式安装这个东西，让我的生活更轻松。我遇到了一些问题，使其像真实且正确的驱动器一样实际安装。有问题的驱动器是 SDB，分区 SDB8 上有我的所有数据。

[dan-mech15g2rx sdb8]# lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda           8:0    1     0B  0 disk  
sdb           8:16   0   1.8T  0 disk  
├─sdb1        8:17   0  19.1M  0 part  
├─sdb2        8:18   0    18M  0 part  
├─sdb3        8:19   0   954M  0 part  
├─sdb4        8:20   0   953M  0 part  
├─sdb5        8:21   0   191M  0 part  
├─sdb6        8:22   0   954M  0 part  
├─sdb7        8:23   0   976M  0 part  
└─sdb8        8:24   0   1.8T  0 part  
  └─md127     9:127  0   1.8T  0 raid1 
nvme0n1     259:0    0   1.8T  0 disk  
├─nvme0n1p4 259:1    0 381.5G  0 part  
├─nvme0n1p5 259:2    0   300M  0 part  /boot/efi
├─nvme0n1p6 259:3    0  31.3G  0 part  [SWAP]
├─nvme0n1p7 259:4    0   250G  0 part  /
└─nvme0n1p8 259:5    0   1.2T  0 part  /home

mdadm 已将其组装到 md127 中。它是 1（一）个驱动器的 Raid1 阵列。是的，我知道这很荒谬，但这就是预建 NAS 的组装方式。

[dan-mech15g2rx sdb8]# mdadm -Dv /dev/md127
/dev/md127:
           Version : 1.2
     Creation Time : Sat Jul 13 20:02:09 2013
        Raid Level : raid1
        Array Size : 1949349781 (1859.04 GiB 1996.13 GB)
     Used Dev Size : 1949349781 (1859.04 GiB 1996.13 GB)
      Raid Devices : 1
     Total Devices : 1
       Persistence : Superblock is persistent

       Update Time : Sun Apr 30 14:35:46 2023
             State : clean 
    Active Devices : 1
   Working Devices : 1
    Failed Devices : 0
     Spare Devices : 0

Consistency Policy : resync

              Name : BA-001075392B1C:1
              UUID : fca7e030:4cde51c2:8d9cd534:be1158a5
            Events : 96133

    Number   Major   Minor   RaidDevice State
       0       8       24        0      active sync   /dev/sdb8

当我去安装这个 raid 驱动器时，我得到以下输出。

[dan-mech15g2rx sdb8]# mount /dev/md127 /mnt/sdb8
mount: /mnt/sdb8: unknown filesystem type 'LVM2_member'.
       dmesg(1) may have more information after failed mount system call.

这是我的 LV 组：

[dan-mech15g2rx sdb8]# vgscan
[dan-mech15g2rx sdb8]# lvscan
[dan-mech15g2rx sdb8]# lvdisplay
[dan-mech15g2rx sdb8]# vgdisplay
[dan-mech15g2rx sdb8]#

在过去的几天里，我一直在使用 LV 的东西，但我非常谨慎地防止我的驱动器被擦除作为某种 LV 操作的一部分。我真的很想进入这个驱动器并将文件拉出来，然后将其完全擦除。任何关于如何从这一点出发的想法将不胜感激。

答案1

您可以创建 LVM 块设备的“只读副本”来进行测试，无需担心：

dmsetup create lvm_pv_ro --readonly --table "0 "$(blockdev --getsz /dev/md127)" linear /dev/md127 0"

进而：

pvscan --cache /dev/mapper/lvm_pv_ro
pvs
vgs

更新1

我只是意识到“块设备副本”的创建使 LVM 两次看到相同的 PV，这会导致严重的问题（镜像 btrfs 卷也会出现类似的问题）。也许可以处理这个问题，但使用原始块设备并仅激活 LV 只读应该更容易：

pvscan --cache /dev/md127
vgchange -ay --readonly vg_name
# mount LVs
mount /dev/vg_name/lv_name /path/to/mountpoint

当然，您也可以以只读方式挂载文件系统。奇怪的是，这并不能阻止所有写访问（处理未提交的日志条目是例外）。

相关内容