事出必有因
Windows Server
RAID 維護
BMR 還原
換碟七小時：一台 2008 R2 伺服器的預防性換碟、BMR 還原、與深夜的意外插曲
2026 年 8 月 22 日 ｜ Mr. τ ／ 風雲網通系統有限公司
預防性換碟，聽起來是一件很日常的事。帶著備份、帶著驅動程式、帶著多年的肌肉記憶，下午進場，傍晚完工，晚上請客戶驗收。
但這次，完工後的兩個小時，我站在現場，看著 ERP 系統越來越慢，然後完全連不上。
這篇文章記錄的，就是那一晚發生的事，以及身為工程師，我從中帶走的教訓。
一、這台機器是什麼來歷
客戶是台中的製造業中小企業，核心系統是一套跑在 Windows Server 2008 R2 SP1 上的 ERP。主機是 ASUS RS500-E8-PS4 v2，磁碟控制器是主機板韌體層的 LSI MegaSR——也就是俗稱的「Fake RAID」。
兩顆 Seagate Exos 7E8 已經穩定服役了 8 到 9 年。沒有故障，但年限到了，主動換碟比等到壞掉再換要安全得多。這次換上的是 Toshiba MG10ADA200E，企業級、5 年保固。
⚠ MegaSR 的維運盲點：這種 Fake RAID 在 Windows 層完全隱形。陣列降級、硬碟掉線，作業系統無感知、無告警。唯一的監控方式，是定期重開機進 BIOS（Ctrl+M）確認陣列狀態。
二、為什麼選擇 WSB 備份還原，而不是直接 Rebuild
換碟的方式有很多種。最直覺的是把舊碟直接 Rebuild 到新碟，但這次選擇了 Windows Server Backup（WSB）備份還原途徑，背後有三個考量：
保存原始硬碟：舊碟不直接覆蓋，萬一還原出問題，還有退路。
多一個備份版本：外接硬碟的備份是獨立保存，不依賴舊碟的物理狀態。
速度快：直接從備份還原，不需要等待 2TB Rebuild 的 8 到 16 小時。
邏輯上說得通。但 WSB 途徑在執行時遇到的隱藏問題，比預期多：
WSB 還原途徑的隱藏風險
・還原環境偵測 RAID 陣列不自動：WinRE 看不到 MegaSR 磁碟，需要手動載入驅動，這一步沒準備好就卡在起點。
・外接硬碟搶佔 C: 代號：開機環境下，外接備份硬碟可能被指派到 C: 代號，導致還原目標和備份來源的磁碟代號混亂，需要用 diskpart 手動整理。
・指令長、參數多、容易漏：wbadmin 的還原指令需要同時指定 version、backupTarget、machine、restoreAllVolumes、recreateDisks，每個參數都有對應的坑，少一個就報錯。
・還原完整性無法立即確認：BMR 跑完、系統開機成功，不代表還原是完整的。D: 空白、wbemperf.dll 遺失這類問題，要到進系統之後才會浮現。
三、換碟與 BMR 還原：那些你不會在手冊裡看到的坑
換碟本身不難，難的是 2008 R2 的還原環境有四個地雷，踩過才知道。
什麼是 BMR？
BMR（Bare Metal Recovery，裸機還原）是指在全新或空白的硬碟上，從備份直接還原完整作業系統的程序——包含系統分割區、開機記錄、驅動程式、系統設定，不需要先重新安裝 Windows。Windows Server Backup 的 wbadmin start sysrecovery 就是執行 BMR 的指令。
原廠光碟版本陷阱
原廠安裝光碟是 RTM 版，系統已升至 SP1，點「修復電腦」直接被擋。解法：在安裝畫面按 Shift+F10 開 CMD，繞過版本檢查。
WinRE 看不到 RAID 磁碟
WinRE 不含 LSI MegaSR 驅動，進還原環境後磁碟清單是空的。驅動要事先從 ASUS 官網下載存隨身碟帶去現場，用 drvload 手動載入後，RAID 邏輯磁碟才會出現。
外接硬碟在 CMD 環境沒有磁碟代號
備份存在外接硬碟，CMD 環境不會自動掛載，要用 diskpart assign letter 手動指派代號，才能讓 wbadmin 找到備份來源。
wbadmin 指令不能少參數
外接硬碟含多台主機備份，-machine 參數是必填。新空白硬碟還原必須加 -recreateDisks，否則 wbadmin 找不到分割配置會報錯。
還原完成後，預防性執行 bcdedit /enum all 加上 bcdboot 重建開機記錄，重開機進入 Windows。
但這時發現一個狀況：D: 磁碟是空的。
原本的 Windows Server Backup 任務是完整備份，系統狀態、C:、D: 全部包含在內。但 wbadmin 的 BMR 還原指令（start sysrecovery）只還原系統碟，D: 的資料並不在 BMR 的還原範圍內。
⚠ BMR 只還原系統碟：wbadmin start sysrecovery 的對象是系統分割區（System Reserved + C:），不包含資料碟。即使備份任務有含 D:，BMR 還原後 D: 仍然是空的，需要另外手動還原。
解法是進入 Windows 後，開啟 Windows Server Backup GUI，選擇同一份備份版本，手動把 D: 還原回來。下午五點左右，C: 和 D: 都還原完成，系統順利進入桌面，我請現場員工開 ERP 驗收。
四、「完工」之後，才是真正的問題開始
ERP 開了，但很慢。
我開始排查：硬碟 I/O 延遲正常、網路流量正常、SQL Server 連線數和快取都正常、CPU 和記憶體也沒有壓力。所有硬體指標都指向「沒問題」，但 ERP 就是慢。
到了晚上七八點，情況更糟——使用者端完全連不上 ERP 系統。
診斷過程中的各項指標：
| 診斷項目 | 工具 | 結果 |
|---|---|---|
| 磁碟 I/O 延遲 | typeperf Disk Queue / sec/Read / sec/Write | ✅ 完全正常（Queue < 0.03） |
| 網路流量 | typeperf Network Bytes Total/sec | ✅ 正常（< 400 Bytes/sec） |
| SQL Server | typeperf User Connections / Page Life Expectancy | ✅ 正常（PLE > 2930） |
| 系統檔完整性 | chkntfs C: / D: | ✅ 無 dirty bit |
| 資源監視器 | resmon.exe | ❌ 畫面空白（wbemperf.dll 遺失） |
五、真正的根因：一個不小心的按鍵
排查到最後，把 Seagate 舊碟放回去，系統立刻正常了。
這讓我回想起在 LSI MegaSR BIOS 設定陣列的過程。
根本原因是：在設定 RAID 參數的過程中，不小心觸發了 Consistency Check（一致性檢查）。
什麼是 Consistency Check？
CC 是 RAID 控制器的陣列巡邏機制，會在兩顆硬碟之間逐一比對每個區塊的資料是否一致。這個程序完全在控制器層執行，OS 層的 typeperf 看不到它的 I/O 流量，但它會佔用磁碟資源，造成前景 I/O 的延遲。
症狀：硬碟燈規律閃爍（Disk 0 閃完接 Disk 1 閃，每秒三到四次），系統越來越慢，工具指標卻顯示一切正常——和硬體故障的症狀幾乎一模一樣。
2TB 陣列的 CC 預估需要 4 到 8 小時。
這也解釋了為什麼把舊碟放回去就正常了：舊碟換入，CC 中斷重置，I/O 壓力解除。
六、處置方式：用舊碟當種子，重建陣列
既然確認問題，就選最穩的路：以 Seagate Exos 7E8 做為 Disk 0 種子碟，Toshiba 新碟置於 Disk 1，讓 MegaSR 自動以 Exos 為來源進行 Rebuild。
MegaSR 如何判斷 Rebuild 方向？
MegaSR 透過每顆硬碟內部的 metadata sequence number 判斷哪顆是「較新的來源」。操作關鍵是：先單獨插入 Exos 開機進 BIOS，讓它的 sequence number 更新為最新；再插入 Toshiba，MegaSR 就會自動選 Exos 為來源、Toshiba 為目標開始 Rebuild。這是經驗判斷，不是手冊裡教的。
Rebuild 啟動後，進度跑到 2 到 3% 確認穩定，時間已是晚上 8 點 52 分。預估還需要 5 到 6 小時，我離開現場，請業主隔天早上驗收。
七、隔天早上 08:30，業主的四個確認
RAID 1 陣列重建完成（100%），兩顆硬碟均正常納入陣列
Windows Server 2008 R2 SP1 正常開機進入桌面
ERP 系統在使用者端電腦上存取順利，反應速度恢復正常
硬碟燈號正常，無高頻異常閃爍情況
八、這次帶走的教訓
進 MegaSR BIOS 要謹慎，CC 很容易誤觸
CC 的症狀與硬體故障幾乎相同，但 typeperf 等 OS 層工具看不到它的 I/O。下次進 BIOS 前，先把每個選項看清楚再按。
硬碟燈的閃爍節奏是診斷線索
Disk 0 閃完接 Disk 1 閃、規律且固定頻率，這是 CC 或 Rebuild 的特徵，不是 I/O 負載。觀察燈號節奏，比單看 typeperf 更快找到方向。
MegaSR Rebuild 方向由 sequence number 決定，操作順序是關鍵
先插來源碟、開機進 BIOS 讓 sequence number 更新，再插目標碟——這個順序不對，MegaSR 可能選錯方向。這是經驗，不是手冊。
BMR 只還原系統碟，D: 要另外手動還原
wbadmin start sysrecovery 只處理系統分割區，即使備份任務有含資料碟，BMR 完成後 D: 仍是空的。還原完成後要記得進 Windows，用 WSB GUI 補還資料碟。
2008 R2 BMR 有三個地雷，要先備妥才能上場
RTM 光碟版本不符、WinRE 無 MegaSR 驅動、外接硬碟無代號——這三個坑不是到現場才發現的問題，是要在出發前就準備好答案的問題。
Fake RAID 的維運盲點，要主動告訴客戶
MegaSR 不會在 Windows 裡告訴你陣列壞了。每季一次定期重開機進 BIOS 確認，這個習慣要幫客戶建立起來，不能等到出事才說。
MegaCLI / StoreCLI 對 MegaSR 完全無效
這次過程中也確認過：MegaCLI 和 StoreCLI 都是針對真正的 LSI MegaRAID 硬體卡設計，MegaSR 完全不在管理範圍內。想在 Windows 層監控陣列狀態，唯一根本解法是換掉 MegaSR，改用有獨立管理介面的硬體 RAID 卡。
512e 不等於 4K，判斷磁區格式要看完整規格
過程中曾懷疑新碟 Toshiba MG10ADA200E 的 512e 格式（進階格式）與 MegaSR 相容性問題，後來確認原本的 Seagate Exos 7E8 也是 512e，服役 8–9 年都正常，所以 512e 本身不是問題根因。512e 是「實體 4K 磁區、邏輯 512 位元組模擬」，對老系統的相容性比原生 4K（4Kn）好得多，但在遇到系統變慢時仍值得列入排查清單，先排除再繼續。
結語
這次從下午兩點進場，到晚上將近九點離場，總共七個小時。預計三小時的工作，加上四小時的意外處置。
意外不是因為不夠謹慎，而是因為 MegaSR 就是這樣一個沒有彈性、沒有警告、只靠燈號說話的控制器。
帶走八個教訓，下次就能少走一段冤枉路。這就是記錄案例的意義。
Mr. τ ／ 風雲網通系統有限公司（PCPiLOT）
我們是放大鏡，聚集世上的光與熱
Comments