核心架構：IS 服務與 ESE 引擎的分層協作

• Information Store (IS) 服務： 處理信箱/公用資料夾的所有儲存操作請求 (MAPI、SMTP、POP3、IMAP4、WebDAV)。
• Extensible Storage Engine (ESE / JET Blue)： 微軟自研 ISAM (索引循序存取法) 資料庫引擎，支援 ACID 交易、多版本並發控制 (MVCC)、B+ 樹索引、線上備份/還原。廣泛用於 AD、DHCP、WINS、SRS 等核心服務。

儲存群組與資料庫檔案結構

每個儲存群組 (Storage Group, SG) 包含：

• .edb (Exchange Database)： 豐富文字/MAPI 格式郵件、資料夾結構、權限、規則、檢視定義。
• .stm (Streaming Database)： 純文字/MIME 格式郵件 (Internet 郵件)，提升 SMTP 流量處理效能。
• .log (Transaction Logs)： 5MB 固定大小循環日誌檔 (E00.log, E01.log...)，記錄所有尚未寫入資料庫的交易操作。
• .chk (Checkpoint File)： 標記已寫入資料庫的日誌位置 (指標)。
• res1.log / res2.log： 預留保護日誌空間，防止磁碟滿時仍有空間寫入關鍵日誌。

EDB 與 STM 協同工作機制

關鍵點： .edb 保存信箱結構 (資料夾階層、權限、規則)，.stm 僅存郵件內容。兩者透過內部物件 ID 關聯，**缺一不可，嚴禁單獨操作 (移動/刪除/備份單一檔案)**。

交易日誌 (Transaction Logs) 的三大核心價值

1. 交易持久性保證 (ACID 中的 D - Durable)： 記憶體修改完成 → 立即寫入日誌 (循序寫入，極快) → 交易宣告完成 → 背景非同步將日誌回寫 .edb/.stm (隨機 I/O，較慢)。確保系統當機不丟失已認可交易。
2. 災難恢復關鍵： 完整備份 (Full Backup) 後至災難發生前的所有變更，皆記錄於日誌中。還原備份後，ESE 自動重放 (Replay) 關聯日誌，將資料庫恢復至災難發生前一刻狀態 — **RPO (資料復原點目標) = 0**。
3. 檢查點機制： E0x.chk 記錄已回寫資料庫的日誌位置。ESEUTIL /MK 可檢視檢查點位置 (如 checkpoint: 0x8,26d1,29 表示 E000008.log 第 26d1 頁已回寫)。

循環日誌 — 絕對禁止的「偷懶」選項

啟用循環日誌後，日誌檔案固定數量循環覆寫，**斷裂了「備份後至災難前」的完整日誌鏈**，導致災難恢復只能回到最後一次完整備份時間點，**所有中間資料永久遺失**。微軟強烈不建議生產環境啟用；僅適合測試環境或極度缺乏磁碟空間且接受資料遺失風險的場景。

資料庫掛載與恢復流程

1. ESE 讀取資料庫標頭 狀態旗標：Clean Shutdown (正常關閉) → 直接掛載；Dirty Shutdown (非正常關閉/當機) → 執行 軟性恢復。
2. 軟性恢復： 從檢查點位置向前掃描日誌，重做 (Redo) 所有已認可交易，回滾 (Undo) 未認可交易，確保資料庫一致性後掛載。
3. 硬性恢復 (ESEUTIL /R /P /D /C...)： 軟性恢復失敗 (資料庫損毀) 時，管理員手動執行離線修復/重建/去碎片，風險極高，必須先完整備份原始檔案。

管理員實務建議

• 分離儲存： .edb/.stm 放在 RAID 10/SSD 陣列；.log/.chk 放在獨立 RAID 1/SSD 陣列 (不同物理磁碟)，提升 I/O 隔離與容錯。
• 備份策略： 每日完整備份 (VSS 快照/線上備份 API) + 持續增量備份；定期離線 ESEUTIL /MH 檢查資料庫健康狀態 (Dirty Shutdown 計數)。
• 監控指標： 日誌產生速率 (MB/hr)、可用磁碟空間、檢查點深度 (當前日誌 - 檢查點日誌)、資料庫掛載狀態、事件日誌 1022/1018/1019 (資料庫損毀預警)。

結語

Exchange 儲存架構以 ESE 引擎為核心，透過 EDB/STM 雙格式分離、日誌先行寫入、檢查點追蹤、軟性恢復自動重放 實現高效能與零資料遺失 (RPO=0) 的雙重保證。深入理解三體協同機制，是制定備份策略、排查效能瓶頸、執行災難恢復的必修課。