PVE折腾笔记 (2) 挂载之前在QNAP里使用的硬盘
前言
在上一篇文章中，我们已经完成了 PVE 系统的安装
接下来做的就是在 PVE 里读取之前 QNAP 使用的硬盘里的数据
去除 RAID 标记（可选）
我没有启用 QNAP 的 RAID 功能，是把每块硬盘单独使用的
这情况我称之为：「伪 RAID」
不过尽管如此，QNAP 还是单独把每块盘都加入了一个 RAID 阵列
因为要把系统安装到硬盘上（在这次的例子中是固态硬盘），所以要分一个区出来备份原本的文件，等系统装完再放回去
但是有“Linux RAID member”标记的分区是不能调整大小的，必须先去掉 RAID 标记
前提：确保该分区能直接挂载，并能看到里面的文件，文件系统正常。
必须使用 Live 系统，这里我推荐 LinuxMint 的 Live 系统，自带很多工具，好用~
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 跑起来
# 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 命令的输出：
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）
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 的时候，报错了：
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'”。
这时候先用只读的方式把数据挂出来
# 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 写入后，两台的数据就分叉了。这会导致远程节点无法再同步，强制重同步会覆盖你刚写的数据。
安全步骤
无视了风险之后，可以跟着这个步骤来，确保数据的安全性。
卸载只读挂载
umount /mnt/qnap_data
umount /mnt/qnap_pan
文件系统一致性检查（强烈推荐）
e2fsck -f /dev/vg290/lv3 # Data1 卷
e2fsck -f /dev/vg289/lv2 # Data2 卷
这一步会在必要时修复 ext4 日志，确保后续读写安全。
正常挂载为读写
mount /dev/vg290/lv3 /mnt/qnap_data1
mount /dev/vg289/lv2 /mnt/qnap_data2
确认可写
touch /mnt/qnap_data1/__test && rm /mnt/qnap_data1/__test
持久化到 /etc/fstab（示例）
UUID=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
然后执行
systemctl 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 hashInvalid HTREE directory inode … Clear HTree index? |
目录的 HTree 索引块（加速大目录遍历的 B-Tree）损坏，校验失败 | 目录索引会被 fsck 删除并重建，不会损坏文件本身 |
这是典型的 “目录索引轻度腐坏”，并非文件内容损坏。e2fsck 只会删掉/重建索引，而不会删除实际文件。
错误出现的可能原因
- QNAP 早期版本格式化 ext4 时 默认不开
dir_index，但后续又给目录打了索引标志 → 不一致。 - 长期断电、不安全关机也可能让目录索引块 checksum 错位。
- 与 LVM / DRBD / RAID 层数无关——这些错误发生在 ext4 的最高层，fsck 修复只改 ext4 元数据。
修复
最稳妥的方案是先做快照，再 fsck
# 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 是否启用
tune2fs -l /dev/vg290/lv3 | grep 'Filesystem features'
如果你看到 dir_index ⇒ 说明 fsck 已自动启用并重建索引，一切 OK。
如果没有 dir_index，可以手动打开再跑一次 fsck –D：
tune2fs -O dir_index /dev/vg290/lv3
e2fsck -fD /dev/vg290/lv3
更多安全措施
SMART 全盘自检
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，才好管理
PVE折腾笔记 (2) 挂载之前在QNAP里使用的硬盘的更多相关文章
- MacBook外置显卡eGPU折腾笔记
MacBook外置显卡eGPU折腾笔记 硬件选购 当今市场上个人电脑的独立显卡,基本上能选的只有NVIDIA和AMD了,如果你想买外置显卡来打游戏的话,NVIDIA和AMD的都可以,但如果是像我一样准 ...
- Ubuntu Gnome 14.04.2 lts 折腾笔记
unity感觉不爽,于是来折腾gnome3 = = 首先去官网下载ubuntu gnome 14.04.2 lts的包(种子:http://cdimage.ubuntu.com/ubuntu-gnom ...
- 某Hi3516EV300摄像头折腾笔记
最近因工作需要买了某款HI3516DV300开发板,但是价格死贵,于是在国内某著名电商网站上瞎逛,很巧发现一家店铺买摄像头模组,主控HI3516EV300,cmos是IMX335,价格不到200元,然 ...
- ASP.NET Core 折腾笔记二：自己写个完整的Cache缓存类来支持.NET Core
背景: 1:.NET Core 已经没System.Web,也木有了HttpRuntime.Cache,因此,该空间下Cache也木有了. 2:.NET Core 有新的Memory Cache提供, ...
- ASP.NET Core 折腾笔记一
前言: 在ASP.NET Core 1.0时,曾折腾过一次,后因发现不了System.Data而停止. 更因VS2015提示过期Delete掉VS了,其实主要还是笔记本的硬盘空间吃紧. 快双十一了,本 ...
- systemtap折腾笔记
在这货上花费了不少时间,都是受了@agentzh 大神的蛊惑:) 他写的nginx-systemtap-toolkit监测的数据很有价值,对于系统优化实在是利器. 最早折腾systemtap,是在Ub ...
- 【转】Kali Linux 新手折腾笔记
原作者:http://defcon.cn/1618.html 最近在折腾Kali Linux 顺便做一简单整理,至于安装就不再多扯了,估计会出现的问题上一篇文章<VMware虚拟机安装Kali ...
- kali linux 2.0 折腾笔记
1. 配置SSH远程登录 root@kali:~# vi /etc/ssh/sshd_config #PermitRootLogin without-password PermitRootLogin ...
- Kali Linux 新手折腾笔记
http://defcon.cn/1618.html 2014年09月29日 渗透测试 暂无评论 阅读 55,052 次 最近在折腾Kali Linux 顺便做一简单整理,至于安装就不再多扯了,估 ...
- Kali WSL折腾笔记-在Windows10上使用Kali子系统
前言 Windows10在发布WSL(Windows Subsystem for Linux)后经过多次更新,现在使用体验已经比较良好,下面简单记录一下我在安装Kali WSL中遇到的种种问题,为各位 ...
随机推荐
- workman PHPSocket.IO文档
安装 请使用composer集成phpsocket.io. 脚本中引用vendor中的autoload.php实现SocketIO相关类的加载.例如 require_once '/你的vendor路径 ...
- 在 Mac/Windows 系统中使用 Laradock 搭建基于 Docker 的 Laravel 开发环境
Laradock 是 Docker 提供的完整 PHP 本地开发环境的一个镜像,任何环境下都可以安装 Docker来运行此开发环境,墙裂安利 简介 Laradock 是为 Docker 提供的完整 P ...
- 找到占用磁盘最多的文件或目录，可以使用du和sort
想要找到占用磁盘最多的文件或目录,可以使用du和sort命令: du -h /path/to/directory | sort -rh | head -n 10 其中: du -h /path/t ...
- linux查看分区命令和根分区扩容方法
df 查看文件系统磁盘空间的使用情况df [选项].[FILE]...当我们指定文件参数FILE时,将会显示该文件所在系统的信息-a 显示出所有的文件系统,包括大小只有0 blocks的文件系统:-h ...
- 响应式编程之Project Reactor
Project Reactor作为响应式编程范式的核心实现框架,严格遵循Reactive Streams规范体系,其架构设计完整包含了规范定义的四个核心组件:Publisher(数据源).Subscr ...
- 【视频编辑】Pr视频编辑软件导出的视频声音有一段会变大怎么解决
导出视频后为什么有段声音会突然变大? 也就是可能存在编辑器导出的时候有自动增益声音的行为. 具体描述: 工程文件里我没动过声音,工程文件里听也是很正常的,但是导出后有一小段音乐会突然变大(存在自动增益 ...
- Windows 延缓写入失败及解决方法
场景重现 某天系统弹出警告:某盘符延缓写入失败 解决办法 [Win + R]或手搓打开cmd.exe,键入chkdsk: 然后等待校检完成. 完成之后到警告提示对应的盘符下进行查错并修复 然后等待检查 ...
- 学习unigui【20】unistringGrid
做成下面效果图: 采用unistringGrid控件. 问题: 1.不同的日期区间如何得到.如: 项目 开始时间时间 -- 终止使用时间 呼吸机 yyyy-mm-dd yyyy-mm-dd ...
- study Python3【3】的函数
Python的函数定义简单,但灵活度非常大.功能强大意味复杂.为了复习,把廖雪峰老师的该课程做个回顾. 参数有:必选参数.默认参数.可变参数.关键字参数.命名关键字参数. 计算x的n次方函数: def ...
- Spring的AoP(面向切面编程)
作用: 就是把我们程序重复的代码抽取出来,在需要执行的时候,使用动态代理的技术,在不修改源码的 基础上,对我们的已有方法进行增强. 优势: 减少重复代码 提高开发效率 维护方便 AoP的实现方式:动态 ...