前情提要：
Day 16 結尾留了一個重大的架構風險揭露：HDP 的備份儲存庫、Day 13 的 AI 模型庫、Day 2 到 Day 8 的容器持久化卷（Persistent Volumes），以及 PVE 的 VM 虛擬磁碟，全部集中在同一台 NAS 的同一個儲存池中。

這意味著儲存設備本身就是最大的單點故障（SPOF）。今天要正面解決「整台儲存設備出事」時的災難復原問題。使用工具為 QuTS hero 的 ZFS 快照與 Hybrid Backup Sync 3（HBS 3），目標是落實 3-2-1 備份架構中的前兩個數字，最後的異地與雲端「1」則留待 Day 18 處理。

一、現況盤點：紙上有備份，機器上其實沒有

很多維運事故的根源，不在於沒有設計備份，而在於「以為系統有在備份」。

為了掌握真實狀態，使用唯讀腳本 nas-audit.sh 進行體檢。該腳本無須 root 權限，透過 SSH 執行 zfs list、zfs get、解析快照排程設定檔、檢查 HBS 3 套件狀態及 rsync 模組組態。分別對主 NAS 與作為備份標的的次要 NAS 進行全面盤點：

兩台設備現況對照表

⚠️ 維運警示
主 NAS 上遺留的兩個 HBS 3 備份目的地，指向早前已除役的設備。控制台上的備份卡片寫著「備份前先建快照」與「快速檢查」，看似處於受保護狀態，實際上需要再強化過。
這種「看似有備份」的假象比完全沒有備份更危險，因為它提供了致命的安全錯覺。

此外，檢查主 NAS 的 Public 資料集時，發現屬性 qnap:zfs_snapshot_maxid 的值為 7，這代表過去手動建立過快照隨後又手動刪除。這證明快照機制在系統中是可行的，只是從未被制度化納入自動排程。

二、容量分級策略：0.9 TB 的次要 NAS 如何接盤 4.8 TB？

受限於硬體條件，次要 NAS 的兩個儲存池可用容量加總僅約 0.9 TB，而主 NAS 實際已使用 4.8 TB。不可能進行全機 1:1 鏡像，必須進行資料分級（Data Classification）。

分級的判斷標準只有兩個：

1. 該份資料是否為全架構中的「唯一副本」？
2. 萬一資料損毀，從零重建所需的時間與頻寬成本為何？

資料分級與備份目的地配置

三個關鍵架構決策說明

1. AI 模型權重全面放棄本地次要複製：
   高達 2.9 TiB 的模型權重無法塞進次要 NAS。考量到這些權重隨時能從 Hugging Face、Ollama 等公開來源重新拉取，且 Day 13 建立的 Manifest 校驗清單能夠嚴格驗證重抓檔案的一致性，故不複製。重新拉取的時間成本將在 Day 18 納入評估。
2. PVE VM 虛擬磁碟必須維持檔案複製：
   雖然 Day 16 的 HDP 已具備 30 天不可變備份，但副本的形態決定了還原速度。HDP 備份本質為 Restic 的 chunk pack 檔案，在 Day 16 實測中，還原一台 32 GB 的虛擬機需要 569 秒，而透過 RTRR 同步出來的是一份立即可掛載的 qcow2 實體磁碟，PVE 只要將次要 NAS 掛載為 NFS 儲存節點，即可直接開機掛載（演練 4 將進行量測）。
3. 重要營運資料強制寫入 Mirror 儲存池：
   HDP_Business 與容器組態放進具備雙碟 Mirror 的 zpool2。容量精算後，zpool2 承載約 407 GB 資料（佔比 72%），剩餘空間全數預留給次要 NAS 本地的 ZFS 快照增量空間。

三、快照設計：防誤刪與勒索，但防不了儲存池硬體故障

快照排程與生命週期設定

機制剖析：快照不等於備份

• 快照不能計入 3-2-1 的獨立副本：主 NAS 只有一個儲存池，快照與即時資料存放在同一組實體磁碟上。一旦整個儲存池壞軌或控制器故障，兩者同步毀滅。快照的職責是解決人為誤刪、客體端勒索軟體攻擊與應用程式錯誤變更。
• NFS 客戶端的快照盲區：在 QuTS hero 架構下，NFS 客戶端無法直接進入快照目錄取檔。因為 @Recently-Snapshot 實際上是另一個內部掛載資料集，掛載後對 NFS 而言為空目錄，且其內部符號連結指向 NAS 本地絕對路徑，.zfs 亦未直接匯出。單檔還原必須由 NAS 本地 Shell、File Station 或透過 SMB 的「以前的版本」進行。
• 快照回滾（Revert）的非預期代價：演練 2 實測顯示，回復一個 20 GB 的目錄，會導致整台 NAS 的 NFS 服務全面凍結近 6 分鐘。因此：單一檔案救急用 Copy-out 取回，整目錄回滾必須安排停機維護窗口。

四、HBS 3 同步配置：同步不帶版本，版本交給對端 ZFS

HBS 3 核心參數設定

架構設計精髓：解耦「同步」與「版本」
本設計將「多版本管理」的責任從備份軟體層抽離，轉移到底層 ZFS 快照。即使主端不幸在清晨被勒索軟體加密，單向同步在 04:00 將受損檔案同步過去，次要 NAS 在前一天 05:00 建立的底層唯讀快照依然完好無損。這也是次要 NAS 快照保留期設定為 14 份的原因。

五、3-2-1 備份原則落實現況檢視

面對資料安全，摒棄口號式的宣稱，透過嚴格的標準實事求是地審視目前架構：

六、災難還原量測體系：三支關鍵檢驗腳本

不同於虛擬機可以透過監控「VM 進入 running 狀態」來判定復原成功，共享目錄的還原需要量測資料一致性、屬性維持度與客戶端掛載反應。為此客製了三支量測工具：

測試工具陣容

1. share-canary.sh（金絲雀探針）：
   • 運行於掛載 NFS 共享資料夾的 Linux 計算主機上（非 NAS 本地）。
   • 每分鐘寫入一筆心跳日誌並強制執行 fsync，內部維持一個 64 MiB 的測試負載檔（Payload）及其 SHA256 校驗碼。
   • verify 模式支援快照目錄、副本目錄或原地回滾後的即時目錄，不進行寫入。
   • 透過比對最後一筆心跳距今時間判定狀態：超過 180 秒視為「凍結副本」，最後一筆心跳即為還原點（Recovery Point），未超過 180 秒則在歷史紀錄中搜尋斷層。
2. replica-verify.sh（副本一致性校驗器）：
   • 快速建立全目錄 SHA256 清單（Manifest），提供逐檔比對或依路徑/大小進行快速過濾，取代備份軟體控制台虛幻的「成功」勾選。
3. restore-drill.sh（自動化計時與審計引擎）：
   • 在按下還原動作的瞬間啟動計時。
   • 每 2 秒輪詢目標路徑，依序等待：beats.log 出現 $\to$ Canary 驗證通過 $\to$ Manifest 全量校驗無誤。
   • 自動計算精確的 RTO 與 RPO，並輸出成稽核用的 JSONL 與 Markdown 日誌。

隔離測試環境設計

本次演練建立獨立的共享資料夾 Drill（配置 100 GB Thin Provisioning），內含金絲雀探針與 20 個 1 GB 的隨機二進位資料檔，配置每小時快照，並排入 HBS 3 同步工作。

環境隔離的盲點
演練 2 證實：建立獨立共享目錄僅隔離了資料內容，並沒有隔離儲存控制層的衝擊。 當執行整個共享目錄快照回滾時，NAS 核心會暫停 NFS 守護程序，導致同台 NAS 上其他無關的 Production 業務一同中斷。

七、四大情境還原演練：實測數據與踩坑全記錄

還原演練總體量測矩陣

演練 1：從快照目錄取回單一損壞檔案

• 演練情境：模擬工程師不慎誤刪核心檔案。在 22:00 快照完成後，於 22:00:32 透過 NFS 用戶端刪除 Drill/canary/payload.bin。
• 還原操作：連線進入 NAS 本機，執行 cp -p 將檔案自快照目錄 @Recently-Snapshot/GMT+08_2026-10-01_2200/canary/ 複製回原處。

時間軸解析

[22:00:32] 用戶端刪除檔案，觸發監控計時 -------------------+ (T0)
[22:00:42] NAS 本地完成 cp -p 與 sync (耗時 10 秒)         |
[22:01:03] 用戶端 Canary 通過驗證 (耗時 31 秒) ------------+--> 實質 RTO = 31s
[22:01:41] 22 份檔案全量 Manifest 通過 (耗時 69 秒)

踩坑經驗與技術盲點

1. NFS 客戶端屬性快取延遲（Attribute Caching）：
   NAS 本機僅花 10 秒即完成複製，但客戶端卻在 31 秒時才讀取到檔案。這 21 秒的落差源自 NFS 客戶端的核心快取機制：當客戶端得知檔案被刪除後，會在屬性快取過期（actimeo）前持續認定檔案不存在。向業務端承諾 RTO 時，必須以客戶端真正能存取的時間為準，不能以儲存端命令執行結束為準。
2. 工具盲區修正：
   剛建立不到 30 秒的快照，其最後一筆心跳距離現在不足 180 秒，導致校驗腳本誤判為即時運作中的目錄，往前回溯抓到前一次演練的舊斷層。修復方式是在呼叫時明確指定 CANARY_KIND=frozen 環境變數。

演練 2：整個共享資料夾回復到歷史快照

• 演練情境：資料夾遭大規模破壞。21:00 快照完成後，21:29 寫入 5 個 1 GB 新檔並刪除舊檔 f16 至 f20。21:30 標記為災難發生時間。
• 還原操作：21:38:49 在 QuTS hero 儲存總管點選「回復至 21:00 快照」。

監控時間軸與客戶端行為

實測指標結算：
- 實際復原時間 (RTO)：694 秒（約 11.5 分鐘）
- 資料遺失窗口 (RPO)：1,799 秒（約 30 分鐘，即 21:30 - 21:00）

踩坑經驗與技術盲點

1. 時間消耗在服務重啟而非區塊搬移：
   回滾僅需捨棄 5 GB 的異動指標，底層 ZFS 回滾本質是指標切換，但 QTS 在執行此操作時花費大量時間在服務的停止、依賴性檢查與重啟。
2. NFS Hard Mount 的掛起特性：
   客戶端未產生 Stale File Handle 或 I/O 報錯，核心在硬性掛載下持續重試，服務恢復後無縫繼續，應用程式不需重新打開檔案描述子（File Descriptor）。
3. 危險的「寫入消失窗口」：
   按下回滾後的最初 191 秒內，用戶端的寫入作業依然被儲存端正常接受並確認（fsync 通過）。但隨後回滾生效，這段時間寫入的資料在沒有任何報錯的情況下全數消失！執行目錄快照回滾前，必須在客戶端強制停止所有寫入程序。
4. 全域影響擴散（Critical）：
   兩台執行正式 VM 的 PVE 節點並未掛載 Drill，卻同樣在 21:45 噴出 nfs server not responding。這證實 QuTS hero 在重啟 NFS 服務時是全域停止，導致其他掛載 Public 的運作中虛擬機與容器連帶陷入約 6 分鐘的 I/O 停頓。任何共享目錄的回滾操作，都必須視為全機維護等級的重大事件！

演練 3：從次要 NAS 跨機逆向還原回主 NAS

• 演練情境：主 NAS 儲存池資料損毀，需從備份節點逆向拉回。先以單向同步將 20.1 GiB 數據推至次要 NAS，隨後刪除主 NAS 上的 Drill/data 與 Drill/canary，模擬全損。
• 還原操作：在次要 NAS 發起逆向 RTRR 同步作業。

逆向還原故障歷程

[22:22:55] 刪除主 NAS 資料目錄 (T0)
[22:23:16] 觸發次要 NAS 逆向同步
[22:23:20] ❌ 任務失敗中斷！報錯：Folder pairs are invalid or inaccessible
[22:23:56] 手動登入主 NAS，建立空的 data/ 與 canary/ 目錄結構
[22:24:28] 重新啟動同步作業
[22:32:51] 資料傳輸完畢 (傳輸 429 秒，平均速率 47.7 MiB/s)
[22:34:19] Manifest 完整性驗證通過 (總 RTO = 684s，RPO = 534s)

踩坑經驗與技術盲點

1. 目錄結構缺失導致同步崩潰：
   HBS 3 的 RTRR 同步在目的地對應目錄完全不存在時不會主動遞迴建立，而是直接判定路徑無效並拋錯終止。真實災難通常就是「整個資料夾遺失」，SOP 第一步必須包含手動建回空目錄。
2. 平鋪目錄導致還原工作碎片化：
   備份時若便宜行事將資料平鋪在次要 NAS 的共享資料夾中，災難復原時為了避開對端既有資料，只能拆解成多個子資料夾獨立配對，大幅增加人為操作時間與出錯機率。
3. 非對稱的傳輸吞吐性能：
   正向備份時速率達 77.6 MiB/s，逆向還原卻降至 47.7 MiB/s。主因在於次要 NAS 作為讀取來源端時，受到 2.5 吋筆電硬碟隨機讀取效能的瓶頸限制。災難復原的時間估算必須以「逆向讀取實測值」為基準，切莫套用日常備份的寫入速率。

演練 4：PVE 直接掛載副本磁碟瞬時開機（Crash-Consistent 驗證）

• 演練情境：針對 vm:100（Windows 11 工作站，磁碟實際佔用 70.3 GiB），驗證直接利用次要 NAS 副本開機的可行性。
• 還原操作：將次要 NAS 的副本目錄透過 NFS 掛載至 PVE，以原參數建立 VM 9100，將磁碟路徑指向該副本並觸發開機。

關鍵致命盲點：快照一致性對虛擬磁碟的決定性影響

在首次同步時，刻意關閉「備份前先建快照」選項，檔案傳輸順利結束且 HBS 3 標記綠色打勾。隨後在 PVE 上使用 qemu-img check 對該副本進行底層結構校驗：

qemu-img check /mnt/pve/secondary-nas/images/100/vm-100-disk-0.qcow2

磁碟內部校驗結果對照

技術剖析：為什麼備份軟體顯示成功，磁碟卻壞了？
第一次同步耗時 20 分鐘，虛擬機在運作中持續向記憶體與磁碟寫入。qcow2 格式包含分配對應表（L1/L2 Table）與參考計數表（Refcount Table）。
當 HBS 3 直接以傳統檔案層級進行讀取時，這兩張元數據表是在不同時間點被複製的，導致副本內部產生自相矛盾的指標（refcount=0 reference=1）。此時拿該磁碟開機，作業系統一旦配置新區塊，QEMU 將發生重疊覆蓋寫入，造成災難性的靜默資料損壞。
結論：同步運作中的虛擬機磁碟，備份軟體必須具備底層快照能力，確保鏡像具備崩潰一致性（Crash-Consistent）。

副本即時掛載開機時間軸

開啟快照重新同步後，校驗結果為 0 錯誤。隨後執行正式開機演練：

[23:34:57] vm:100 透過 Guest Agent 正常關機 (耗時 26 秒)
[23:35:24] 寫入 VM 9100 虛擬硬體設定並點擊開機 ------------+ (T0)
[23:35:26] PVE qm start 命令成功返回 (耗時 2 秒)           |
[23:35:34] Windows 核心記錄 Boot 啟動事件 (耗時 10 秒)       |
[23:35:41] NTFS 日誌校驗完畢，宣告檔案系統健康健全          |
[23:35:59] QEMU Guest Agent 回應，成功取得原 IP 位址 -------+--> 實質 RTO = 33s

指標結算：
- 復原時間目標 (RTO)：33 秒（Day 16 HDP 全量還原需 569 秒，大幅縮減 94%）
- 資料復原點 (RPO)：1,270 秒（約 21 分鐘，取決於前一次快照同步時間點）

Windows 事件檢視器記錄了預期的 Kernel-Power 41 與 EventLog 6008，這正是典型的 Crash-Consistent 狀態。此方案能在 33 秒內拉起服務，但代價是該 VM 隨後的所有 I/O 都承載在次要 NAS 的 2.5 吋硬碟上，效能將顯著受限。

八、放進維運手冊的 5 個守則

經歷實戰演練，簡單提出五項維運的原則：

1. 整目錄快照回滾等於全機停機事件：
   QuTS hero 回滾共享資料夾快照會全域性短暫重啟 NFS 守護程序。回滾前必須停止所有寫入者，避免前 3 分鐘的寫入在無警告下憑空消失，這在儲存設備上是嘗試了。
2. NFS 客戶端不能直接進行快照存取：
   客戶端無法透視 ZFS 快照目錄。單檔還原應善用 NAS 本地 Shell、Web 管理介面或 SMB 陰影複製（Shadow Copy），計算 RTO 時得考量客戶端屬性快取失效的時間差。
3. 虛擬磁碟同步必須強制綁定快照：
   HBS 3 同步執行中的虛擬機磁碟時，「備份前先建快照」為強制性設定。備份軟體的傳輸成功不等於區塊可用，驗收必須搭配 qemu-img check。
4. 目的地資料夾必須預先初始化：
   災難還原通常伴隨整層目錄結構的消失。HBS 3 無法在目錄完全缺失時自行建構對應路徑，SOP 首要步驟必須手動確認路徑骨架完整性。
5. 還原時程估算不要去套用自己認知的備份速率：
   備份寫入通常享有記憶體快取與循序寫入紅利，災難復原受限於備份設備的隨機讀取瓶頸，傳輸速率可能銳減 40% 以上。

九、全域斷電與主機全損演練規範（Outage Checklist）

演練 4 驗證了資料層級的掛載，但尚未模擬「主 NAS 硬體實體燒毀」的場景。相關準備工作已納入 outage-checklist.md，幾個不可忽略的架構依賴包含：

• PVE 叢集仲裁仲裁票（QDevice）：
  目前 QDevice 運作於主 NAS 的 Virtualization Station 內部。主 NAS 實體關機期間，PVE 叢集總票數將驟降至兩票，此時任何一台節點發生網絡波動或重啟，叢集將立即失去法定人數（Quorum）而鎖死。
• 虛擬機非預期狀態：
  Day 15 實測證實，當 QTS 系統重啟或關機時，Virtualization Station 僅會對內部 VM 發出「暫停（Suspend）」而非標準關機，重啟後可能引發記憶體狀態不一致。
• 無縫停機量測：
  復原後立即對各資料夾執行 share-canary.sh verify，心跳日誌的斷層區間就是最精確的業務停機時間。

十、自動化驗證腳本操作指南

所有量測工具已開源並整理於專案倉庫中，可依照以下流程進行驗收：

# 取得維運檢驗工具包
git clone https://github.com/ivanusto/nas-backup-drill && cd nas-backup-drill

# 1. 執行唯讀安全性盤點（產出 Markdown 審計報告）
NAS=user@primary-nas ./nas-audit.sh > audit-primary.md
NAS=user@secondary-nas ./nas-audit.sh > audit-secondary.md

# 2. 在掛載了 NFS 的工作節點部署監控探針
sudo ./share-canary.sh install /mnt/drill/canary

# 3. 演練前生成全量校驗 Manifest
./replica-verify.sh manifest /mnt/drill > drill.sha256

# 4. 在按下儲存端還原的瞬間，啟動自動化計時與完整性檢驗
./restore-drill.sh /mnt/drill/canary \
  --label "3. 從次要 NAS 還原" \
  --failed-at 2026-10-02T03:10:00Z \
  --manifest drill.sha256

# 5. NAS 本地端快照點精確時間驗證（避開 NFS 盲區，剛建立之快照指定 frozen）
ssh user@primary-nas "CANARY_KIND=frozen sh -s verify /share/Drill/@Recently-Snapshot/GMT+08_2026-10-01_2200/canary" < share-canary.sh

退出狀態代碼（Exit Code）定義

• 0：驗證完全通過（PASS）
• 2：Canary Payload 校驗碼不符（Data Corruption）
• 3：輪詢逾時，檔案未能在時限內出現（Timeout）
• 4：Manifest 檔案數量或內容比對失敗（Incomplete Restore）

明日預告

已經在兩台實體設備間打通了具備 Crash-Consistent 的備份機制，但目前的架構依然無法防禦整座機房的實體災難。

Day 18｜3-2-1 的最後一步：異地物件儲存、S3 Object Lock 與冷熱資料成本精算
明天將媒體庫外移至 Google Cloud Storage 與 AWS S3，利用真正的 Object Lock 實現無法篡改的「WORM 不可變性」，同時深入計算雲端儲存的 API 請求與傳輸隱藏成本，並制定具備成本效益的異地重建計畫。

相關資源與索引

• 系列文章與程式碼索引：onprem-ops-30days
• 本日演練程式碼：nas-backup-drill