Loading

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 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

# 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

加到 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，才好管理

posted @ 2025-06-15 18:17 程序設計實驗室閱讀(89) 評論(0) 收藏舉報

刷新頁面返回頂部