简要背景
我有一台 QNAP TS-451。 NAS 出现故障，但我很确定驱动器仍然完好。我有一台新的 QNAP TS-462 来尝试更换它，我想确保我的数据在新系统中完好无损。
问题
无法组装RAID时如何访问LVM的内容？
（以下问题的更多详细信息）
环境
这TS-451系统死机，不再启动。它的配置如下：
- 驱动器 A - 20TB RAID1 镜像
- 驱动器 B - 20TB RAID1 镜像
- 驱动器 C - 8TB 无 RAID
- 驱动器 D - 14TB 无 RAID
这TS-462是一个我想要将驱动器 A/B/C/D 迁移到的新系统。
分离Linux系统（理想情况下）从驱动器 A/B/C/D 无损读取数据：
- 软呢帽 38
- Linux内核6.2.14-300
- 旧 BIOS（即我不认为它可以从 GPT 分区启动——在这种情况下不是问题）
- Pentium Dual Core E6500（只是为了让您了解这个系统有多老）
实验1
我尝试将其中一个不重要的驱动器（驱动器 C）移至新的 TS-462，但 TS-462 似乎无法读取它。据我所知，它似乎对分区表感到困惑（fdisk 报告一件事而 blkid/lsblk 报告不同。
在一台单独的 Linux 计算机 (Fedora 38) 上，我能够读取 LVM 并将分区挂载到驱动器 C 和 D 上，并确认文件完好无损。
实验2
所以我尝试做同样的事情来读取驱动器 B。驱动器 A/B 是 RAID1 镜像的一部分，所以我认为在其中一个驱动器上（谨慎地）进行实验并保留另一个驱动器作为备份应该没问题。
不幸的是，我似乎无法激活 LVM。以下是我在 Linux 系统上尝试过的一些事情：
# fdisk -l /dev/sdc
Disk /dev/sdc: 18.19 TiB, 20000588955648 bytes, 39063650304 sectors
Disk model: WDC WD201KFGX-68
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: DFC9F3CE-9CFA-4251-8DD1-48BF99476C04
Device Start End Sectors Size Type
/dev/sdc1 40 1060289 1060250 517.7M Microsoft basic data
/dev/sdc2 1060296 2120579 1060284 517.7M Microsoft basic data
/dev/sdc3 2120584 39045853979 39043733396 18.2T Microsoft basic data
/dev/sdc4 39045853984 39046914269 1060286 517.7M Microsoft basic data
/dev/sdc5 39046914272 39063621869 16707598 8G Microsoft basic data
从我收集到的信息来看http://www.rodsbooks.com/linux-fs-code/，这些分区显示的事实Microsoft basic data并不是问题，而只是证明这是在非常旧的 Linux/fdisk 版本上设置的证据。 （我大约从 2015 年开始就有 TS-451）。
# gdisk /dev/sdc
GPT fdisk (gdisk) version 1.0.9
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/sdc: 39063650304 sectors, 18.2 TiB
Model: WDC WD201KFGX-68
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): DFC9F3CE-9CFA-4251-8DD1-48BF99476C04
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 39063650270
Partitions will be aligned on 8-sector boundaries
Total free space is 28423 sectors (13.9 MiB)
Number Start (sector) End (sector) Size Code Name
1 40 1060289 517.7 MiB 0700 primary
2 1060296 2120579 517.7 MiB 0700 primary
3 2120584 39045853979 18.2 TiB 0700 primary
4 39045853984 39046914269 517.7 MiB 0700 primary
5 39046914272 39063621869 8.0 GiB 0700 primary
# cat /proc/mdstat
Personalities :
md123 : inactive sdc5[1](S)
8353780 blocks super 1.0
md124 : inactive sdc4[25](S)
530124 blocks super 1.0
md125 : inactive sdc1[26](S)
530108 blocks super 1.0
md126 : inactive sdc2[1](S)
530124 blocks super 1.0
md127 : inactive sdc3[2](S)
19521865728 blocks super 1.0
unused devices: <none>
# mdadm --assemble --readonly /dev/sdc3
mdadm: device /dev/sdc3 exists but is not an md array.
为什么？？？ :-(
pvdisplay并且各种 LVM 工具最初并没有发现 LVM。当明确指定分区时：
# pvdisplay /dev/sdc3
Cannot use /dev/sdc3: device is an md component
什么？但mdadm说不是。 :-(
# mdadm --examine /dev/sdc3
/dev/sdc3:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x0
Array UUID : 5a6e38ee:eb6bf302:79856803:58887046
Name : 1
Creation Time : Wed Nov 25 03:18:54 2015
Raid Level : raid1
Raid Devices : 2
Avail Dev Size : 39043731456 sectors (18.18 TiB 19.99 TB)
Array Size : 19521865728 KiB (18.18 TiB 19.99 TB)
Super Offset : 39043733376 sectors
Unused Space : before=0 sectors, after=1920 sectors
State : active
Device UUID : f2a96ebc:996e4231:1576a39a:8606a71c
Update Time : Sun Mar 26 00:56:13 2023
Checksum : 893841dd - correct
Events : 436627
Device Role : Active device 1
Array State : AA ('A' == active, '.' == missing, 'R' == replacing)
校验和很好。那么这是否意味着这是一个有效的 RAID 分区？ （虽然其他分区（甚至交换分区）显示有效的 raid 信息和校验和，所以我不知道这意味着什么。）
让我们尝试一下不同的路线...
然而，通过设置md_component_detection=0,/etc/lvm/lvm.conf并执行pvscan --cache --devices /dev/sdc，我能够获取 LVM 数据......
# pvdisplay /dev/sdc3
--- Physical volume ---
PV Name /dev/sdc3
VG Name vg1
PV Size 18.18 TiB / not usable 0
Allocatable yes (but full)
PE Size 4.00 MiB
Total PE 4766080
Free PE 0
Allocated PE 4766080
PV UUID Xt2uVv-PMCy-oHuK-0UAc-43ZI-z7TH-hHAK7A
# vgdisplay vg1
--- Volume group ---
VG Name vg1
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 131
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 18.18 TiB
PE Size 4.00 MiB
Total PE 4766080
Alloc PE / Size 4766080 / 18.18 TiB
Free PE / Size 0 / 0
VG UUID oNdjeV-lPuv-PgPR-J11o-zbHQ-X7az-93sr9J
# lvdisplay vg1
--- Logical volume ---
LV Path /dev/vg1/lv544
LV Name lv544
VG Name vg1
LV UUID z1gyiX-FhGG-cTaM-shPx-wZg4-G1xN-b9fS37
LV Write Access read/write
LV Creation host, time NASEFF3AE, 2015-11-25 03:18:56 -0800
LV Status NOT available
LV Size 144.00 GiB
Current LE 36864
Segments 2
Allocation inherit
Read ahead sectors 8192
--- Segments ---
Logical extents 0 to 5119:
Type linear
Physical volume /dev/sdc3
Physical extents 0 to 5119
Logical extents 5120 to 36863:
Type linear
Physical volume /dev/sdc3
Physical extents 1428360 to 1460103
--- Logical volume ---
LV Path /dev/vg1/lv1
LV Name lv1
VG Name vg1
LV UUID 4lsaNW-E4Bg-g93F-ko0a-Ep1m-wHD0-3Hc3Cb
LV Write Access read/write
LV Creation host, time NASEFF3AE, 2015-11-25 03:19:03 -0800
LV Status NOT available
LV Size 18.04 TiB
Current LE 4729216
Segments 2
Allocation inherit
Read ahead sectors 8192
--- Segments ---
Logical extents 0 to 1423239:
Type linear
Physical volume /dev/sdc3
Physical extents 5120 to 1428359
Logical extents 1423240 to 4729215:
Type linear
Physical volume /dev/sdc3
Physical extents 1460104 to 4766079
是的，所以我应该能够安装驱动器，对吧？
# vgchange -ay vg1
WARNING: PV /dev/sdc3 in VG vg1 is using an old PV header, modify the VG to update.
device-mapper: reload ioctl on (253:3) failed: Device or resource busy
device-mapper: reload ioctl on (253:3) failed: Device or resource busy
0 logical volume(s) in volume group "vg1" now active
嗯...也许这md_component_detection=0不是正确的方法？
实验3
为了彻底起见，我测试了最重要的、手术刀和测试盘。这些都是不错的工具，但是对于目前的情况我觉得有点麻烦。磁盘应该完美且可读...分区和文件系统完好无损。我假设某个地方存在某种版本不兼容？
目标和问题（重温）
我的目标主要是以某种方式访问我的旧数据（来自驱动器 A/B）。我不介意重新格式化其中一个驱动器并从另一个系统迁移。或者如果我对能够访问数据有任何合理的期望，则将其放入 TS-462 中。
在我当前的路径中（沿着实验 2），我陷入困境的是弄清楚如何让 Linux 识别 RAID？我想我会尝试弗罗斯特舒茨的极好的建议写时复制覆盖共享于从 Linux Raid1 成员磁盘恢复文件 - 尽可能糟糕。
但我愿意接受建议！
答案1
# mdadm --assemble --readonly /dev/sdc3 mdadm: device /dev/sdc3 exists but is not an md array.为什么？？？ :-(
这完全是一个错误的命令；使用 mdadm，您组装的是/dev/md设备，而不是/dev/sd设备。
你可以试试：
mdadm --assemble --run --readonly /dev/md42 /dev/sdc3
但是，您已经为 sdc3 ( /dev/md127) 组装了一个 md 设备，因此在再次组装它之前，您必须mdadm --stop /dev/md127先进行组装。
/dev/sdc3这个现有的 md 设备也应该是您在忽略 raid 层的情况下尝试 vgchange 时看到的“设备繁忙”错误的原因。
答案2
如果您的 QNAP 设备已损坏，您将无法在 Linux 计算机上访问磁盘上的文件。这是因为 QNAP 修改了内核和 lvm 工具。
要访问这些文件，需要从源代码编译 qnap 内核和 qnap 修改后的 lvm 工具。
作为一个为同事（型号 TS-251+）从 qnap 磁盘恢复文件的副项目，我设法编译了一个内核和一个包含 LVM 工具的 initrd，以便可以生成 VM 并访问磁盘上的文件
您可以在以下位置找到内核和说明：https://github.com/thanosz/qnap-kernel-lvm