自動啟動和回復—作業原理

stored 常駐程式將在其他郵件儲存程序之前啟動。它將初始化郵件儲存資料庫，必要時也會回復該資料庫。郵件儲存資料庫中包含有資料夾、配額、訂閱以及郵件旗標等資訊。資料庫可以記錄和作業，因此已經內建回復功能。此外，還會在每個資料夾的郵件索引區域中複製資料庫資訊，做為備用。

雖然資料庫非常穩定，仍可能會偶爾發生損毀，但在大多數情況下，stored 可以透明地回復並修復資料庫。但是，只要 stored 重新啟動，您就應該檢查預設記錄檔，以確定系統不需要額外的管理介入。如果資料庫需要進一步重建，記錄檔中的狀態訊息會要求您執行 reconstruct。

開啟郵件儲存資料庫之前，stored 會分析資料庫的完整性，並將狀態訊息傳送到 warning 類別之下的預設記錄中。某些訊息對管理員很有用，某些訊息則包含已編碼的資料，可供內部分析之用。如果 stored 偵測到任何問題，它將嘗試修正並再次啟動資料庫。

當資料庫開啟後，stored 會通知其餘服務可以啟動。如果自動修復失敗，預設記錄中的郵件將指出應採取何種動作。請參閱表示需要執行 reconstruct -m 的錯誤訊息

在舊版中，stored 可能會啟動極度耗時的復原程序，使得管理員常常擔心 stored 是否「滯塞」。此類耗時的回復方式已被移除，並且 stored 可在一分鐘內決定最終狀態。但是，如果 stored 需要採用從快照回復之類的回復技術，該程序可能會多花費幾分鐘。

多數情況下，資料庫在回復後都可以恢復運作不需再做其他處置。然而，某些回復將需要執行 reconstruct -m，以同步化郵件儲存中的備用資料。這也會記錄到預設記錄中，因此在啟動後監視預設記錄很重要。雖然郵件儲存看起來一切如常，但還是有必要執行 reconstruct 之類的作業。

查閱記錄檔的另一個原因是可以確定損害資料庫的真正元兇。雖然 stored 的設計目的就是要讓郵件儲存能在存在任何其他系統問題的情況下啟動，但您也許還是想查明資料庫損毀的原因，因為這可能是更大潛在問題的徵兆。

表示需要執行 reconstruct -m 的錯誤訊息

本小節說明需要執行 reconstruct -m 的錯誤訊息類型。

當錯誤訊息指出電子信箱錯誤時，請執行 reconstruct <mailbox>。範例：

"Invalid cache data for msg 102 in mailbox user/joe/INBOX. Needs reconstruct"

"Mailbox corrupted, missing fixed headers: user/joe/INBOX"

"Mailbox corrupted, start_offset beyond EOF: user/joe/INBOX"

當錯誤訊息指出資料庫錯誤時，請執行 reconstruct -m。範例：

"Removing extra database logs. Run reconstruct -m soon after startup to resync redundant data"

"Recovering database from snapshot. Run reconstruct -m soon after startup to resync redundant data"

資料庫快照

快照是資料庫的最新備份，stored 可以用它在幾分鐘內透明地復原資料庫。這種方式比依賴其他區域中儲存的備援資訊來運作的 reconstruct 要快得多。

郵件儲存資料庫快照—作業原理

資料庫快照位於 mboxlist 目錄中，依預設每 24 小時自動取樣一次。依預設，快照會複製到 store 目錄的子目錄中。依預設，在任何給定時間，系統會保留五種快照：一個使用中的資料庫，三個快照以及一個資料庫/已移除的副本。已移除資料庫的副本較新，它是資料庫的緊急備用副本，通常放在 mboxlist 資料庫目錄的 removed 子目錄下。

如果復原程序確定目前資料庫已損毀並決定將其移除，則 stored 會將其移至 removed 目錄中 (如果可能)。這樣就可以根據需要對資料庫進行分析。

資料移動每週進行一次。如果已存在資料庫副本，stored 將不會在每次儲存啟動時替代資料庫副本。僅當 removed 目錄中的資料超過一週後，才會進行替代。這是為了防止原先有問題的資料庫在啟動成功後很快被取代。

指定郵件儲存資料庫快照的間隔和位置

所需空間至少是資料庫加上快照空間的五倍。極力建議管理員應重新配置快照以在單獨的磁碟上執行，並根據系統的需求進行調校。

如果 stored 在啟動時偵測到資料庫有問題，就會自動用最新的快照來回復。三個快照變數可以設定以下參數：快照檔案的位置、執行快照的間隔時間以及儲存的快照數目。這些 configutil 參數在表 18–15 中顯示。

如果快照的間隔時間太短，會對系統造成太多負擔並且資料庫中有問題的部分也很可能被複製到快照中。如果快照的間隔時間太長，會造成資料庫只能回復到當初快照時的狀態，中間的變動都會損失掉。

一般的建議是一天作一次快照，如果系統上的問題已存在數天之久，一週份或更多的快照會對回復很有幫助，因為您也許會想將系統復原到問題發生之前的狀態。

stored 會監視資料庫，並且當它懷疑資料庫有問題時，會拒絕使用最新的快照。然後它將擷取儘可能新的最可靠快照。雖然快照可能是一天前擷取的，但如果可用，系統還是會以較新的備援資料來置換較舊的快照資料。

因此快照的最終目的就是要取得系統最近的穩定狀態資料，以減輕系統在正常作業時重建資料的負擔。

表 18–15 郵件儲存資料庫快照的參數

參數	說明
local.store.snapshotpath	郵件儲存資料庫快照檔案的位置。可以是現有絕對路徑，也可以是相對於 store 目錄的路徑。 預設：dbdata/snapshots
local.store.snapshotinterval	快照間隔的分鐘數。有效值：1 至 46080  預設：1440 (1440 分鐘 = 1天)
local.store.snapshotdirs	所保留的不同版本快照的數目。有效值：2 至 367  預設：3