前言
在上一篇文章中，我们已经完成了 PVE 系统的安装
接下来做的就是在 PVE 里读取之前 QNAP 使用的硬盘里的数据
去除 RAID 标记（可选）
我没有启用 QNAP 的 RAID 功能，是把每块硬盘单独使用的
这情况我称之为：「伪 RAID」
不过尽管如此，QNAP 还是单独把每块盘都加入了一个 RAID 阵列
因为要把系统安装到硬盘上（在这次的例子中是固态硬盘），所以要分一个区出来备份原本的文件，等系统装完再放回去
但是有"Linux RAID member"标记的分区是不能调整大小的，必须先去掉 RAID 标记
前提：确保该分区能直接挂载，并能看到里面的文件，文件系统正常。
必须使用 Live 系统，这里我推荐 LinuxMint 的 Live 系统，自带很多工具，好用~
bash
sudo mdadm --zero-superblock /dev/nvme1n1p1不过这一步发现有不少坑，所以还是整个盘格式化后重新安装吧~
挂载之前 QNAP 里的硬盘
这个 QTS 非常鸡贼，把硬盘搞成了 QNAP 的形状，拿去其他机器上一时之间还不太方便使用。
虽然我从一开始就没用 QNAP 的 RAID，但俩硬盘还是被 QNAP 打上 RAID 标记...
这里不得不点赞一下 Fedora ，对 mdadm 和 LLVM 支持挺好的，我装上后无需其他操作就能用，非常舒服；反观 Debian 这边就没那么容易了。
我一开始咨询了一下大模型爷爷操作步骤，结果给我整了一堆乱七八糟的什么 hexdump -C /dev/sda3 | grep '53 ef' -m 1 和 offset mount 之类的骚操作，结果一点用没有。
后面我参考 Fedora 的思路，把这些单盘都当成 RAID 来用，才解决了这个问题...
第一次尝试
首先我用了以下命令尝试把 RAID 跑起来
bash
# 1) 安装 mdadm（如果系统里还没有）
apt update && apt install -y mdadm
# 2) 侦察 superblock，确认真的是孤立单盘
mdadm --examine /dev/sda3 | less
mdadm --examine /dev/sdb3 | less
# 3) 只读方式临时组阵列并挂载
mdadm --assemble --run --readonly --scan
lsblk -f # 现在应该能看到 /dev/md0, /dev/md1 之类
mkdir -p /mnt/hdd_ro
mount -o ro /dev/md0 /mnt/hdd_ro # 任选一个 md 设备
ls /mnt/hdd_ro # 浏览一下保证文件都在
umount /mnt/hdd_ro结果失败了
以下是 mdadm --examine 命令的输出：
bash
root@pve:~# mdadm --examine /dev/sda3
/dev/sda3:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x0
Array UUID : 82110a99:bed38360:83a46ad3:07cf1ed5
Name : 3
Creation Time : Wed Oct 5 20:52:11 2022
Raid Level : raid1
Raid Devices : 1
Avail Dev Size : 7794127240 sectors (3.63 TiB 3.99 TB)
Array Size : 3897063616 KiB (3.63 TiB 3.99 TB)
Used Dev Size : 7794127232 sectors (3.63 TiB 3.99 TB)
Super Offset : 7794127504 sectors
Unused Space : before=0 sectors, after=272 sectors
State : clean
Device UUID : 39fc7080:89b1f8e2:b1e87049:e0be897b
Update Time : Thu Jun 5 00:26:17 2025
Checksum : b0d6c53d - correct
Events : 38
Device Role : Active device 0
Array State : A ('A' == active, '.' == missing, 'R' == replacing)
root@pve:~# mdadm --examine /dev/sdb3
/dev/sdb3:
Magic : a92b4efc
Version : 1.0
Feature Map : 0x0
Array UUID : 384872c5:5115e767:8a1b1743:21a92774
Name : 2
Creation Time : Wed Oct 5 20:51:31 2022
Raid Level : raid1
Raid Devices : 1
Avail Dev Size : 7794127240 sectors (3.63 TiB 3.99 TB)
Array Size : 3897063616 KiB (3.63 TiB 3.99 TB)
Used Dev Size : 7794127232 sectors (3.63 TiB 3.99 TB)
Super Offset : 7794127504 sectors
Unused Space : before=0 sectors, after=272 sectors
State : clean
Device UUID : b9812252:6926d965:a4742fdd:002a808b
Update Time : Thu Jun 5 00:26:17 2025
Checksum : eb9e7ff0 - correct
Events : 38
Device Role : Active device 0
Array State : A ('A' == active, '.' == missing, 'R' == replacing)之后我执行了 mdadm --assemble --run --readonly --scan 命令，正常，没有报错
接下来是 lsblk -f 命令的输出，可以看到能正确识别出原来两个硬盘的 Level 了（Data1 和 Data2）
bash
root@pve:~# lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sda
├─sda1 linux_raid_ 1.0 9 8150abf9-12a5-e494-3788-e27afd1724d6
│ └─md9
├─sda2 linux_raid_ 1.0 256 e9614eab-cd95-5094-e256-6e821fece908
│ └─md256 swap 1
├─sda3 linux_raid_ 1.0 3 82110a99-bed3-8360-83a4-6ad307cf1ed5
│ └─md3 drbd v08 7e1eee85c60383a8
│ ├─vg290-lv546
│ └─vg290-lv3 ext4 1.0 Data1 fea46d46-360a-43ab-b08d-3b6611d5febb
├─sda4 linux_raid_ 1.0 13 9683911f-8ce2-1590-d4ef-ad48834a11d6
│ └─md13
└─sda5 linux_raid_ 1.0 322 69c648ec-bff1-f508-2a33-68e853686173
└─md322 swap 1
sdb
├─sdb1 linux_raid_ 1.0 9 8150abf9-12a5-e494-3788-e27afd1724d6
│ └─md9
├─sdb2 linux_raid_ 1.0 256 e9614eab-cd95-5094-e256-6e821fece908
│ └─md256 swap 1
├─sdb3 linux_raid_ 1.0 2 384872c5-5115-e767-8a1b-174321a92774
│ └─md2 drbd v08 1701cfea3a83aeca
│ ├─vg289-lv545
│ └─vg289-lv2 ext4 1.0 Data2 41416d24-8e6c-410b-a352-99a7906d01b2
├─sdb4 linux_raid_ 1.0 13 9683911f-8ce2-1590-d4ef-ad48834a11d6
│ └─md13
└─sdb5 linux_raid_ 1.0 322 69c648ec-bff1-f508-2a33-68e853686173
└─md322 swap 1
mmcblk0
├─mmcblk0p1 vfat FAT16 94A6-6032
├─mmcblk0p2 ext2 1.0 QTS_BOOT_PART2 cb599a87-2d25-4bbf-b539-2a63d15fe65b
├─mmcblk0p3 ext2 1.0 QTS_BOOT_PART3 446fd8ae-09c9-461e-acf8-64c0ea7d5d59
├─mmcblk0p5 ext2 1.0 1675f897-f7d6-4770-adf1-52b4029caa6b
├─mmcblk0p6 ext2 1.0 c3670c22-10b5-4432-8e2e-538946b979b2
└─mmcblk0p7 ext2 1.0 e281a9c0-35f1-4238-bed9-19517c854d5a
mmcblk0boot0
mmcblk0boot1
nvme0n1
├─nvme0n1p1 vfat FAT32 9232-1821
├─nvme0n1p2 ext4 1.0 17a25403-2cb7-45e5-8964-4c875c523f0f
└─nvme0n1p3 btrfs fedora d54dac0a-639d-452a-8a81-30ac674d5503
nvme1n1
├─nvme1n1p1
├─nvme1n1p2 vfat FAT32 DEF4-57C4 1010.3M 1% /boot/efi
└─nvme1n1p3 LVM2_member LVM2 001 SRQLSp-m0jk-epeM-a0zD-OVMa-hkRH-YO2cSG
├─pve-swap swap 1 dbef4bdc-0425-454b-a60e-876d03a5965d [SWAP]
├─pve-root ext4 1.0 6c380545-526f-4214-a261-8413efe88ec6 85.5G 4% /
├─pve-data_tmeta
│ └─pve-data
└─pve-data_tdata
└─pve-data但当我打算挂载 md3 的时候，报错了：
bash
root@pve:~# mount -o ro /dev/md3 /mnt/hdd_ro
mount: /mnt/hdd_ro: unknown filesystem type 'drbd'.
dmesg(1) may have more information after failed mount system call.
mount: (hint) your fstab has been modified, but systemd still uses
the old version; use 'systemctl daemon-reload' to reload.第二次尝试
分析原因：/dev/md3 和 /dev/md2 外面看是 mdadm "单盘阵列"，但里面 QNAP 又套了一层 DRBD （用于做自家快照/双机复制），再在 DRBD 之上放 LVM，最后才是 ext4。
mdX ──▶ drbdX ──▶ VG29x ──▶ LV (ext4)
所以直接挂载 /dev/md3 会得到 "unknown filesystem type 'drbd'"。
这时候先用只读的方式把数据挂出来
bash
# 0. 确保工具齐全
apt install -y lvm2 drbd-utils # drbd-utils 可有可无，保险起见装上
# 1. 激活 LVM 里的卷（DRBD 已经自动 primary，lsblk 能看到 lv）
vgscan
vgchange -ay # 把 vg289 / vg290 激活
# 2. 创建挂载点
mkdir -p /mnt/qnap_data1 # sda3 里的 ext4 (label=Data1)
mkdir -p /mnt/qnap_data2 # sdb3 里的 ext4 (label=Data2)
# 3. 只读挂载
mount -o ro /dev/vg290/lv3 /mnt/qnap_data1
mount -o ro /dev/vg289/lv2 /mnt/qnap_data2
# 4. 验证
ls /mnt/qnap_data1 | head
ls /mnt/qnap_data2 | head这次激活了 LVM 的卷之后，终于能挂载成功了，也能看到里面的文件了，芜湖~
接下来怎么做
已经解决了读取数据的问题，如何处理之前 QNAP 的硬盘呢？接下来有几种选择：
| 方案 | 操作 | 适用场景 |
|---|---|---|
| 留着不动 | 继续用 md+DRBD+LVM | 最省事、100% 不破坏数据 |
| 拆掉 DRBD only | drbdadm down → lvconvert --config 卸 metadata（或直接复制到新盘） |
不需要分布式复制，只想少一层 |
| 彻底重做 | 全盘备份 → mdadm --zero-superblock → 重新分区/ext4/ZFS |
想把两块盘当普通盘或 ZFS 使用 |
拆掉 DRBD only 有点麻烦，彻底重做这个简单粗暴，用新的硬盘备份数据，之后重新格式化原来的硬盘。
所以这里就只介绍继续用 留着不动（md+DRBD+LVM） 的方案。
对了，顺带一说，我选择的方案是用新的硬盘备份数据，旧硬盘重做... 毕竟是 NAS，稳定优先
继续使用原硬盘
风险
留着不动的话，一旦开始使用，后续就不建议继续把这个硬盘用回 QNAP 的 QTS 系统了，原因是 QNAP 会在 LVM 里创建隐藏快照卷（thin snapshot）。如果直接在 PVE 里写入原卷，快照与主卷之间的依赖关系就被打破------QNAP 再拿这块盘时可能无法回滚/删除快照。
后续把硬盘插回 QNAP 时，系统可能会报错或提示"快照损坏"，严重时卷无法挂载。
另外，关于 QNAP 双机同步 / 远程复制（DRBD 同步）功能，体现在之前看到的 drbd 元数据，这代表了集群 A 的第 0 块磁盘，最后同步到某版本号。如果另一台 NAS 里还有"副本盘"，在 PVE 写入后，两台的数据就分叉了。这会导致远程节点无法再同步，强制重同步会覆盖你刚写的数据。
安全步骤
无视了风险之后，可以跟着这个步骤来，确保数据的安全性。
-
卸载只读挂载
bashumount /mnt/qnap_data umount /mnt/qnap_pan -
文件系统一致性检查（强烈推荐）
bashe2fsck -f /dev/vg290/lv3 # Data1 卷 e2fsck -f /dev/vg289/lv2 # Data2 卷这一步会在必要时修复 ext4 日志，确保后续读写安全。
-
正常挂载为读写
bashmount /dev/vg290/lv3 /mnt/qnap_data1 mount /dev/vg289/lv2 /mnt/qnap_data2 -
确认可写
bashtouch /mnt/qnap_data1/__test && rm /mnt/qnap_data1/__test -
持久化到 /etc/fstab（示例）
bashUUID=fea46d46-360a-43ab-b08d-3b6611d5febb /mnt/qnap_data1 ext4 defaults,noatime 0 2 UUID=41416d24-8e6c-410b-a352-99a7906d01b2 /mnt/qnap_data2 ext4 defaults,noatime 0 2然后执行
bashsystemctl daemon-reload mount -a
文件系统一致性检查
使用原硬盘之前，有一步是文件系统一致性检查，使用了 e2fsck 命令。
我用这个命令的时候，扫描出来一些错误，这里也记录和分析一下：
主要有几类错误：
Pass 1: Checking inodes, blocks, and sizes Inode 36831239 has INDEX_FL flag set on filesystem without htree support. Clear HTree index<y>?Pass 2: Checking directory structure Problem in HTREE directory inode 36831239: block #1 has bad max hash Problem in HTREE directory inode 36831239: block #2 has bad min hash Invalid HTREE directory inode 36831239 (/Data/Music/M-hM-^KM-1M-fM-^VM-^G). Clear HTree index<y>?
先把报错翻译成人话
| 报错 | 含义 | 影响 |
|---|---|---|
Inode ... has INDEX_FL flag set on filesystem **without htree support** |
目录条目打了"已开启目录索引"的标记，但整个文件系统 super-block 并没有声明 dir_index 特性 |
只是 元数据不一致 ；清掉标记或给 FS 打开 dir_index 即可 |
Problem in HTREE directory inode ...: bad max/min hash Invalid HTREE directory inode ... Clear HTree index? |
目录的 HTree 索引块（加速大目录遍历的 B-Tree）损坏，校验失败 | 目录索引会被 fsck 删除并重建，不会损坏文件本身 |
这是典型的 "目录索引轻度腐坏" ，并非文件内容损坏。e2fsck 只会删掉/重建索引，而不会删除实际文件。
错误出现的可能原因
- QNAP 早期版本格式化 ext4 时 默认不开
dir_index，但后续又给目录打了索引标志 → 不一致。 - 长期断电、不安全关机也可能让目录索引块 checksum 错位。
- 与 LVM / DRBD / RAID 层数无关 ------这些错误发生在 ext4 的最高层，fsck 修复只改 ext4 元数据。
修复
最稳妥的方案是先做快照，再 fsck
bash
# 1) 给逻辑卷做写时复制快照，10 GiB 足够应付元数据回滚
lvcreate -s -L 10G -n lv3_snap /dev/vg290/lv3
# 2) 对原卷执行自动修复（全程 -y 自动确认）
e2fsck -fy -C0 /dev/vg290/lv3
# 3) 没问题就删掉快照
lvremove /dev/vg290/lv3_snap如果 fsck 过程中真的出大事（极小概率），lvconvert --merge /dev/vg290/lv3_snap 就能把卷回滚到快照时刻。
修复后，再次检查 dir_index 是否启用
bash
tune2fs -l /dev/vg290/lv3 | grep 'Filesystem features'如果你看到 dir_index ⇒ 说明 fsck 已自动启用并重建索引，一切 OK。
如果没有 dir_index，可以手动打开再跑一次 fsck --D：
bash
tune2fs -O dir_index /dev/vg290/lv3
e2fsck -fD /dev/vg290/lv3更多安全措施
SMART 全盘自检
bash
smartctl -t long /dev/sda跑完用 smartctl -a 查看结果
定期离线备份
RAID/LVM/DRBD 只是可用性，不是备份。
建议用 vzdump 或 rsync 把重要文件推到另一台机器或云端。
加到 PVE 存储池
Web UI → Datacenter > Storage > Add > Directory，路径选 /mnt/qnap_data1 或 /mnt/qnap_data2，用途根据需求勾选。如图：
只读挂载目录的限制
大模型爷爷告诉我：在 Proxmox VE（PVE）中理论上可以添加只读目录为存储池
但我实际使用的时候，还是报错了：
create storage failed: mkdir /storage/data/template: Read-only file system at /usr/share/perl5/PVE/Storage/Plugin.pm line 1543. (500)算了，等备份完重新做存储池吧~
到时可能还得研究下 LVM 之类的东西
小结
这么看下来，群晖和威联通之类的成品 NAS 用的技术也太老了吧
搞了那么多层套娃，最终实现还不如 ZFS 和 BTRFS 呢
最后结论就是，要把之前在 QTS 里使用的硬盘继续拿来用，最好还是重新格式化，做成 ZFS 或者 BTRFS，才好管理