前言

沒想到到了 Day 04 才終於出現前言。今天要介紹的內容非常多，而且已經接近儲存系統的底層邏輯。我前面提過，我不希望這個系列只是帶著大家複製貼上指令，而是希望各位真的理解 PVE 與叢集部署背後使用的原理。

我原本很猶豫要不要刪減內容，或乾脆拆成兩天，最後還是決定盡可能整理在同一篇。這篇文章經過不少次修改、補充與資料查找，內容可能稍微長了一些，也希望它真的能在各位規劃儲存時派上用場。

今天要解決的問題

PVE 安裝完成後看到的 ext4、local 與 local-lvm 分別是什麼？RAID 與 ZFS 解決的是不是同一個問題？Snapshot 能不能直接當成備份？如果資料還要跨越多台 PVE 主機，又需要哪一類儲存方式？

這些問題不能直接從 PVE 的 Storage 選單找答案，因為選單同時混合了檔案系統、磁碟管理、共享儲存與分散式儲存。接下來會從一個檔案開始，逐步擴大到一顆磁碟、多顆磁碟，最後才是多台 PVE 節點。

本文閱讀方式

• 完整理解技術與底層原理：依序閱讀全文。
• 掌握完成部署所需的基本概念：優先閱讀標有「⭐」的章節。
• 快速了解當天的部署內容：閱讀文末的 Lab／實作章節。
• 跟著系列建立完整系統：依照 GitHub 詳細部署文件 的天數順序操作。

⭐ 檔案系統是什麼

磁碟本身只提供一格一格的資料區塊，不知道什麼是檔名、資料夾或權限。檔案系統會替這些區塊建立管理規則，記錄檔案名稱、目錄結構、擁有者、權限，以及每份資料實際位於哪些區塊。

ext4 是 Linux 常見的檔案系統。它可以管理檔案與目錄。可以把 ext4 想成圖書館的編目制度：它知道每一本書叫什麼、放在哪個書架、誰可以讀取。至於圖書館如何劃分空間、有幾棟建築，則是下一層處理的問題。

常見的 Linux 檔案系統

檔案系統解決的共同問題，是把沒有檔名概念的資料區塊，整理成可以建立目錄、保存檔案、設定權限並在異常關機後恢復的結構。不同檔案系統的差異，主要在資料配置方式、日誌、快照、校驗、擴充能力與適合的工作負載。

FAT32、exFAT 與 NTFS 也很常見，但主要用於隨身碟、跨作業系統交換或 Windows 系統，不是本系列 PVE 主機儲存的選擇，因此不在這裡展開。

從 MBR 到 GPT：一顆磁碟如何分區

各位小時候玩電腦中毒要重灌的時候，都有經歷過重新劃分磁碟分割區的經驗吧。這些分割區實際上是怎麼切出來的？電腦又如何知道每一區的範圍？

一顆新磁碟只是一段連續的儲存空間。分割表記錄磁碟上有哪些分割區，以及每個分割區從哪裡開始、在哪裡結束。常見格式是較早期的 MBR 與現在普遍使用的 GPT。

MBR（Master Boot Record，主開機記錄）誕生於 BIOS 與小容量磁碟的年代。它把開機程式碼與主要分割資訊放在磁碟開頭，設計簡單、相容性高，但後來遇到容量、分割區數量與可靠性限制。要理解第一個容量限制怎麼產生，必須先知道磁區與 LBA 是什麼。

磁碟不會直接用第幾個檔案定位資料，而是先切成許多可以定址的磁區（Sector）。傳統磁碟每個磁區通常是 512 Bytes，意思是系統會以每 512 Bytes 為一個編號單位。LBA（Logical Block Addressing，邏輯區塊定址）就是替這些磁區依序編號，讓分割表可以用 "從第幾號磁區開始、總共有幾個磁區" 描述一個分割區。

因此 MBR 主要有以下三個限制：

• MBR 分割區項目只能用 32-bit 欄位記錄起始 LBA 與磁區數量，最多只能表示約 2^32 個磁區。在每個磁區 512 Bytes 的情況下，2^32 × 512 Bytes 約為 2TiB，因此超過這個範圍的空間無法使用傳統 MBR 完整描述。
• 原生只有四筆主要分割區（Primary Partition）記錄。超過時必須建立延伸分割區（Extended Partition），再於其中建立邏輯分割區（Logical Partition）。
• 主要分割表集中在磁碟前端，沒有 GPT 那種標準化的備份表與 CRC 完整性檢查。

GPT（GUID Partition Table，GUID 分割表）就是為了解決容量、分割區數量與分割表可靠性問題。它使用更大的 LBA 位址範圍，每個分割區都有類型 GUID 與唯一 GUID，一般工具通常預留 128 筆分割區項目，不再需要延伸分割區。磁碟前後各保存主要與備份 GPT，並使用 CRC32 檢查 Header 與 Partition Entry Array 是否損壞。

可以把分割表想成建築物的平面圖。分割區（Partition）則是依照平面圖隔出的房間。分割區可以直接格式化成 ext4，也可以交給 LVM、軟體 RAID 或其他儲存技術使用。當範圍從一顆磁碟擴大到多顆磁碟時，接下來要先處理的是容量、效能與磁碟故障問題，也就是 RAID。

傳統 RAID

理解 RAID 表格前，先認識三個常見動作：

• 資料分條（Striping）：把資料拆開，分散寫入多顆磁碟。可以增加容量與吞吐量，但本身沒有副本。
• 鏡像（Mirroring）：把相同資料寫入兩顆以上磁碟。會犧牲容量，換取磁碟故障時仍有另一份資料。
• 同位元檢查（Parity）：根據多顆磁碟的資料計算額外校驗資訊。它比完整鏡像節省容量，但寫入與故障重建需要額外計算及讀取。

N 代表磁碟數量，S 代表陣列中最小磁碟的容量。表中的倍數是以相同磁碟組成陣列時，相對於單碟的理論速度。實際結果仍會受到控制器、工作負載、Queue Depth 與磁碟本身影響。

圖（一）常見 RAID Level 的資料分布方式。

圖片來源：IP With Ease〈What is RAID? 5 Types of RAID Levels〉

熱備援、重建與 RAID 控制器

熱備援磁碟（Hot Spare）是 RAID 控制器或軟體 RAID 提供的選用功能。它平時不保存有效資料。當成員磁碟故障時，系統可以自動把它加入陣列並開始重建。

重建方式取決於 RAID Level。RAID 1 會把正常的鏡像複製到新磁碟。RAID 5／6 則讀取其餘資料與同位元資訊，重新計算故障磁碟原本的內容。重建期間陣列依然可運作，但 I/O 會增加，而且在冗餘尚未恢復前，再發生磁碟故障的風險更高。這也是為甚麼有人會建議購買硬碟時使用不同批號，如果硬碟同時損壞多顆或是重建時再次損壞，那麼資料很大概率就沉入海底了。

具備電池或快閃記憶體保護寫入快取的硬體 RAID，可以保存尚未落盤的寫入。

⭐ LVM 讓磁碟空間更容易調整

RAID 解決多顆磁碟如何組合與容錯，組合完成後，作業系統通常會看到一個可供使用的區塊裝置。若直接在這個裝置上建立固定分割區與 ext4，日後重新分配容量還是不夠方便。LVM（邏輯磁碟區管理）會在區塊裝置與檔案系統之間再加入一層抽象。

LVM 並不一定要建立在 RAID 上。PV 可以是一整顆磁碟、一個 GPT 分割區，也可以是 RAID 建立後提供的邏輯裝置。

圖（二）LVM 將一個或多個 PV 集合成 VG，再從 VG 分配不同用途的 LV。

PV 是交給 LVM 管理的容量來源。多個 PV 可以合併成 VG，再從 VG 切出不同大小的 LV。

也就是加入 LVM 後，ext4 看到的底層裝置變成 LV，而不是直接綁定原本的磁碟分割區。ext4 仍然管理檔案。LVM 則負責聚合與切分容量。日後擴大 LV，再擴大 ext4，檔案系統就能使用新增的空間。

先用下圖理解 PVE 使用 ext4＋LVM 時的抽象層級：

圖（三）PVE 使用 LVM 的概念分層。

這張圖用來表示層級關係，不是 PVE 預設分割配置的逐項還原。黃色區域代表由 VG 分配的邏輯磁碟區。一般 LV 可以格式化為 ext4、XFS 等檔案系統，而圖中的 data 則被指定為 Thin Pool 使用。

LVM-thin 會再加入精簡配置（Thin Provisioning）。建立一顆標示 40GB 的 VM Disk 時，不必立刻占滿 40GB 實體空間，而是隨著 VM 寫入逐步使用容量。這讓所有 Thin Volume 的標示容量總和可以暫時超過目前的實體空間，也就是超額配置（Over-provisioning）。但資料真的寫滿 Thin Pool 時，還是會發生 I/O Error，甚至造成 Guest 檔案系統損壞。

到這裡，傳統路線可以整理成「磁碟或 RAID 邏輯裝置 → PV → VG → LV → ext4／XFS」。ZFS 則是整合磁碟管理、冗餘與檔案系統的另一種做法。

ZFS 不只是「軟體 RAID」

傳統做法通常先把多顆磁碟組成 RAID，再於邏輯磁碟上建立前面介紹過的 ext4 或 XFS。ZFS 則把磁碟區管理與檔案系統整合在一起：先將磁碟組成儲存池（ZPOOL），再從池中建立 Dataset 或 ZVOL。

圖（四）傳統檔案系統與 ZFS 儲存池的差別。

圖片來源：Escape〈在 Linux 上安裝和使用 ZFS〉

圖（五）ZFS 寫入時複製：先將新資料寫入另一個區塊，完成後再切換中繼資料指標。

假設檔案原本使用資料區塊 A，現在要修改其中一段內容。ZFS 不會直接覆蓋 A，而是把新內容寫到另一個空間 A'。A' 完整寫入後，才讓中繼資料改指向 A'。如果切換前突然斷電，舊的 A 還是存在。切換完成後，系統才使用 A'。這就是寫入時複製（Copy-on-Write）。

ZFS 也會替每個資料區塊保存校驗和（Checksum）。讀取時若內容與校驗和不符，就能發現磁碟雖然回傳資料、內容卻已損壞的情況，也就是靜默資料損毀（Silent Corruption）。

ZFS 的磁碟配置要先從 VDEV 開始理解。VDEV（Virtual Device，虛擬裝置）是 ZFS 儲存池的基本組成單位，可以由單顆磁碟、鏡像磁碟，或具有同位元保護的 RAIDZ／dRAID 磁碟群組構成。一個或多個頂層 VDEV 再組成儲存池（ZPOOL）。

ZPOOL 之上可以建立 Dataset 與 ZVOL。Dataset 是能設定配額、壓縮、掛載點與快照的 ZFS 檔案系統。ZVOL 則把儲存池中的空間提供成區塊裝置，PVE 可以用它保存 VM Disk。ZPOOL 會把資料分散到所有頂層 VDEV。任何一個頂層 VDEV 完全失效，通常就會失去整個儲存池。

ZFS 與 LVM 的差別

LVM 是區塊裝置管理工具，主要工作是把磁碟或 RAID 提供的空間建立成 PV、集合為 VG，再切分成 LV。LV 本身仍只是區塊裝置。若要保存一般檔案，還要另外格式化成 ext4、XFS 等檔案系統。磁碟冗餘、資料校驗與檔案系統功能，也通常要分別交給 RAID 和上層檔案系統處理。

ZFS 則把磁碟管理、儲存池、冗餘與檔案系統整合在同一套設計中。VDEV 負責磁碟配置，ZPOOL 集合可用空間，Dataset 直接提供檔案系統，ZVOL 則提供類似 LV 的區塊裝置。ZFS 同時知道資料區塊、校驗和與副本的位置，因此在具有冗餘時可以偵測並修復損壞資料，這不是 LVM 單獨能完成的功能。

因此，VG 與 ZPOOL、LV 與 ZVOL 只能用來幫助理解概念，不能視為完全相同的技術。PVE 常見的兩條路線分別是：

磁碟或 RAID → LVM → LV／LVM-thin → ext4、XFS 或 VM Disk
磁碟 → ZFS VDEV → ZPOOL → Dataset 或 ZVOL

一般不需要在 ZFS 上再建立 LVM，否則會增加儲存層級，讓容量、快照與故障排除變得更複雜。

不使用 LVM-thin，不代表 ZFS 不能超額配置。PVE 的 ZFS Storage 啟用 sparse 後，會使用 ZFS Thin Provisioning 建立 Sparse ZVOL。例如 VM 看見一顆 100GB 虛擬磁碟，底層不會立刻保留完整的 100GB，而是隨著實際寫入逐步消耗 ZPOOL 空間。因此，多台 VM 宣告的虛擬磁碟容量總和仍然可以超過目前實體可用容量。代價也和 LVM-thin 類似：如果所有 VM 後來真的把空間寫滿，ZPOOL 還是可能耗盡並造成寫入失敗，所以必須持續監控實際用量並保留安全空間。

圖（六）VDEV、ZPOOL、Dataset 與 ZVOL 的層級。

圖片來源：Reddit r/zfs 討論串〈I am still confused about ZFS after reading many articles〉

ZFS 磁碟配置與 RAID 的對照

這些倍數和前面的 RAID 表格一樣，是相對於同型單碟的大型循序 I/O 理論上限。

傳統 RAID 5／6 若在更新資料與同位元資訊的途中斷電，可能只完成其中一邊，造成兩者不一致。這種狀況稱為寫入漏洞（Write Hole）。ZFS 以寫入時複製和交易式更新處理資料與中繼資料，不會把只完成一半的更新直接視為有效狀態。不過，這不代表 RAIDZ 在所有工作負載下都會比鏡像快。實際上要根據資料需求參考以上表格選擇。

當 ZPOOL 由鏡像、RAIDZ 或 dRAID 提供冗餘時，資料巡檢（Scrub）會逐筆讀取資料並驗證校驗和。發現錯誤後，可以利用正確副本修復損壞資料。單碟 ZFS 依然能發現錯誤，卻沒有第二份資料可以修復。

ZFS 除了磁碟，也會使用 RAM 與日誌

VDEV 決定容量與容錯，實際效能還會受到記憶體快取與同步寫入方式影響。

資料去重（Dedup）會比較資料內容，讓相同的區塊只保存一份，但需要大量 RAM 與中繼資料 I/O。壓縮（Compression）則在資料寫入磁碟前先縮小每個區塊。lz4 (壓縮演算法) 的壓縮與解壓縮速度快、CPU 負擔較低，適合作為一般用途的起點，ZSTD 則能換取較高壓縮率，但會使用更多 CPU。

傳統 RAID 與 ZFS 的真正差別

傳統 RAID 通常先由控制器或作業系統把多顆磁碟組成一顆邏輯磁碟，再由 ext4、XFS 等檔案系統把檔案寫入這顆邏輯磁碟。

ZFS 則同時知道磁碟配置、資料冗餘、資料區塊與校驗和。當讀到損壞資料時，若有鏡像或 RAIDZ 副本，就能讀取正確副本並修復錯誤。

沒有冗餘的單碟 ZFS 只能發現錯誤，無法自行修復，錯誤的 VDEV 配置、儲存池滿載、記憶體不足或缺乏獨立備份，一樣可能造成資料遺失。

⭐ 從單機儲存走向跨主機儲存

前面的 ext4、LVM、RAID 與單一 ZFS ZPOOL，都是從同一台主機的磁碟出發。當 VM 需要在多台 PVE 節點之間存取同一份磁碟資料時，儲存範圍就必須再往外擴大。

常見做法包括由外部儲存設備提供 NFS／iSCSI，或由多台節點共同組成 Ceph 分散式儲存。前者把共享空間集中交給一套外部儲存系統。後者則把資料與副本分散到多台主機。

Ceph 會在後續教學完整介紹。屆時才會說明資料如何分布、節點故障後為何依然能存取，現在的話我們先專注於單機的儲存系統。

⭐ 回到 PVE：Storage 如何選

知道了這麼多，我們回頭來看 PVE 介面的 Storage：

local 是檔案型儲存，可以直接看到 ISO、Cloud Image、Container Template 與 vzdump 備份檔。但它通常位於系統碟，因此不適合無限制堆放大型備份。local-lvm 是區塊型的 LVM Thin Pool，適合保存 VM／Container Disk，不能像一般資料夾一樣上傳 ISO。若安裝 PVE 時選擇 ZFS，則通常會看到 local-zfs。VM Disk 使用 ZVOL，Container Root Filesystem 則使用 ZFS Subvolume。

後續建立 Ceph 後，PVE 也會把 Ceph RBD 顯示成另一個 Storage。它同樣可以保存 VM Disk，但資料不是只放在單一節點的本機磁碟，而是由 Ceph 分散到多台節點。

那麼在 PVE 按下 Resize disk 時，實際擴大的是哪一層？答案取決於 VM Disk 位於哪一種 Storage。本系列使用 local-lvm 時，每顆 VM Disk 是 LVM-thin 裡的一個 Thin Volume，PVE 會先擴大這個虛擬區塊裝置。接著要進入 Guest OS，依序擴大分割區與檔案系統，新增空間才會真的出現在作業系統裡。若 VM Disk 位於 Directory、ZFS 或 Ceph，底層則可能是映像檔、ZVOL 或 RBD，不一定是 LV，但 Guest OS 仍要處理自己的分割區與檔案系統。

⭐ Storage 之後，才是 Snapshot 與 Backup

Storage 決定 VM Disk 放在哪裡。Snapshot 與 Backup 則決定發生操作錯誤或故障後，可以回到哪一個時間點。

Snapshot 建立得快，但原始 Storage 損壞或空間用滿時，Snapshot 也可能一起失去。真正的備份應存放在不同故障域。

Snapshot 的核心是保存某個時間點的磁碟狀態。實際機制會依 Storage 而不同，例如 LVM-thin、ZFS 與 Ceph RBD 都有自己的快照能力，但共同點是之後的新寫入會與快照保留的舊狀態分開追蹤。因此建立速度通常很快，額外空間則會隨著需要保留的舊資料區塊逐步增加。如果持續保留大量快照，會增加容量與管理負擔。

Backup 則會產生可以另外保存並用來還原的備份資料。即使使用 PVE vzdump 的 Snapshot Mode，這裡的 Snapshot 只代表備份過程盡量維持 VM 運作，最後仍會產生備份檔。備份檔若和原始 VM 放在同一顆實體磁碟，雖然形式上是備份，卻共用同一個故障域。磁碟損壞時可能一起消失，所以正式環境還要把備份送到另一台主機、另一套儲存或異地位置，並定期實際執行 Restore。

Proxmox Backup Server（PBS）是獨立安裝的備份伺服器。PVE 把 VM／Container 備份傳送到 PBS 的 Datastore，再由 PBS 處理增量備份、資料去重、完整性驗證、保留週期與異地同步。

本次 Lab 實作摘要

GitHub 實作文件：詳細部署步驟

知道理論後我們來實際操作一次，完整操作順序放在 GitHub。實驗機為 ext4＋LVM-thin 配置。

快照只做一次簡單示範：選擇一台測試 VM，進入 Snapshots → Take Snapshot，名稱填入 test。建立後可以在同一頁看到快照與 Rollback。

圖（七）在 PVE 的 VM Snapshot 頁面建立 test 快照。

可以自行建立快照，再進入 VM 新增檔案並執行 Rollback，確認 VM 是否回到建立快照時的狀態。篇幅關係，本文只保留操作入口與結果畫面，完整步驟放在 GitHub 實作文件。

接著我們來看備份。

排程備份則從 Datacenter → Backup → Add 建立。Node 選測試 VM 所在節點、Storage 選 local、Schedule 選預計執行的時間，Selection mode 選 Include selected VMs，只加入測試 VM。Mode 使用 Snapshot，Compression 使用 ZSTD。儲存後可以選取 Job 按 Run now 立即測試，再到節點 → local → Backups 確認備份檔與 Restore 按鈕。

圖（八）從 Datacenter 建立 vzdump 排程備份工作。

這裡的 Backup Mode 名稱雖然也叫 Snapshot，意思是備份時盡量維持 VM 運作，不代表產生的 vzdump 備份檔等同於 VM Snapshot。

本次排程只用於示範。確認備份成功後，請停用或刪除此 Backup Job，避免它持續執行並占滿 local 儲存空間。

今天完成後應該理解什麼

• ext4、XFS 與 Btrfs 是不同設計取向的檔案系統。ZFS 還進一步整合了儲存池、冗餘與資料完整性功能。
• MBR 與 GPT 都是分割表。GPT 解決了 MBR 的容量、分割區數量與分割表完整性限制。
• GPT、LVM、檔案系統與 RAID 位於不同儲存層級，可以依需求組合使用。
• RAID 與 ZFS 處理單機內的磁碟配置。跨主機儲存還需要 NFS、iSCSI 或 Ceph 等後端，這些技術都不能取代備份。
• 快照適合短期回復，但不等於異機備份。
• 快照與備份的差異，不只在建立方式，也在於是否能保存到不同故障域並獨立還原。

下一篇預告

下一篇將說明實體網卡、Linux Bridge 與 VLAN Trunk。儲存決定資料放在哪裡，虛擬網路則決定 Management、Service、Database 與其他 VLAN 如何到達每台 VM。

同時也會先替 Ceph 準備獨立的 Storage Network 與空白 OSD 磁碟，並說明 Ceph Public Network、Cluster Network、Corosync Network 為什麼不能全部當成同一種流量。下一篇只完成網路與磁碟前置作業。Ceph MON、MGR、OSD、RBD 與 CephFS 會等 PVE Cluster 建立完成後再正式部署。

參考資料

• Linux Kernel：ext4 資料結構與設計
• UEFI Specification：GPT Disk Layout
• Red Hat：LVM 架構與 PV、VG、LV
• Proxmox VE：Storage
• Proxmox Backup Server：架構與功能
• OpenZFS：Copy-on-Write、Dataset、校驗、壓縮與巡檢
• OpenZFS：VDEV、RAIDZ、dRAID 與 Special VDEV