|
| |
| Sun Java System Calendar Server 6 2005Q1 管理指南 | |
第 22 章
疑難排解本章包括一些可以用於確定系統是否有問題以及問題出現之原因的疑難排解技術。本章包含以下主題：
啟用除錯資訊由於沒有一個可以將整個系統置於「除錯模式」的 ics.conf 參數，所以本小節說明一些獲得有用除錯資訊的方法：
提昇記錄層級
使用表 22-1 中顯示的參數提昇記錄的詳細度：
表 22-1 用於啟用除錯模式的 ics.conf 參數
參數
說明和預設值
logfile.loglevel
設定為 DEBUG 以獲得所有記錄的層級 (包括 CRITICAL、ALERT、ERROR、WARNING、NOTICE 和 INFORMATION)。此設定可套用於所有記錄。
如需有關不同記錄的更多資訊，請參閱使用 Calendar Server 記錄檔。
啟用對 LDAP 快取記憶體的存取記錄
若要記錄對 LDAP 資料快取記憶體的所有存取情況並列印記錄 (報告)，請設定表 22-2 中所顯示的 ics.conf 參數。
使用 Calendar Server 公用程式監視系統
使用以下 Calendar Server 公用程式監視系統：
如需關於 Calendar Server 公用程式的更多資訊，請參閱附錄 D「Calendar Server 指令行公用程式參照」。
疑難排解 LDAP 問題本小節包含與 LDAP 問題有關的主題：
Calendar Server 公用程式不工作
如果您是首次建立託管環境，則必須透過增加適當的網域、容器、使用者和資源項目在 LDAP 中建立 DC 樹狀結構。如果使用 Calendar Server 公用程式 (例如 cscal) 時 DC 樹狀結構還不存在，您可能會看到以下錯誤訊息："Initialization failed .... exiting".
確定您的 DC 樹狀結構在 DC 樹狀結構根目錄下至少包含一個 (預設) 網域。使用增加託管網域 (Schema 1)中的說明建立 DC 樹狀結構。
疑難排解遷移公用程式Calendar Server 提供了數個用於遷移行事曆資料庫和 LDAP 目錄的公用程式。本小節包含以下主題：
呼叫技術支援之前所要執行的工作
一般情況下，如果您在使用遷移公用程式時遇到疑難，則應該先收集好以下資訊，然後聯絡技術支援：
遷移公用程式的位置
各遷移公用程式及其文件位於以下清單中所指定的位置：
- 模式遷移公用程式 (commdirmig) ─ 此公用程式是與 Access Manager 同時安裝的。它將 LDAP 目錄從 Schema 1 遷移到 Schema 2。如需有關此公用程式的資訊，請參閱「Sun Java System Communications Services 6 2005Q1 Schema Migration Guide」。
- Calendar Server 5.x 至 Calendar Server 6.x 遷移公用程式 (cs5migrate 和 cs5migrate_recurring) ─ 技術支援提供包含公用程式及其文件的遷移束。
- csmig ─ 此公用程式與 Calendar Server 一同安裝。包含疑難排解小節的文件位於第 4 章「資料庫遷移公用程式」中。如果您要使用託管網域和 LDAP 行事曆查找資料庫 (CLD) 外掛程式，則必須執行此公用程式。
- csvdmig ─ 此公用程式與 Calendar Server 一同安裝。相關文件位於第 4 章「資料庫遷移公用程式」中。使用此公用程式準備用於託管網域的行事曆資料庫和 LDAP 目錄項目。
- Calendar Server 2.x 至 Calendar Server 6.x 遷移公用程式 (ics2migrate) ─ 此公用程式與 Calendar Server 一同安裝。相關文件位於第 4 章「資料庫遷移公用程式」中。使用此公用程式遷移 Calendar Server 2.x 以與 Calendar Server 5.x 相容。
- Netscape Calendar Server 4.x 至 Calendar Server 5.x 遷移公用程式 (ncs4migrate) ─ 僅可從技術支援處獲得此公用程式。公用程式套裝軟體中包含相關文件。此公用程式可將 Netscape Calendar Server 4.x 遷移至 Calendar Server 5.x。請特別注意這些遷移。可以考量使用專業服務協助您規劃遷移。
疑難排解 Calendar Server本小節包括多種用於非資料庫問題的疑難排解方法。本小節包括以下主題：
對行事曆服務執行 Ping 作業
若要驗證服務是否正在偵聽指定的連接埠號碼，請使用 cstool 公用程式 ping 指令。對某種服務執行 ping 作業不會驗證該服務是否確實正在執行，但會指示該服務是否可以接受套接字連線。
Calendar Server 服務選項為：
必須執行 Calendar Server，才能執行 cstool。
例如，對主機名稱為 calserver 的機器執行 ping 作業，以查看 cshttpd 服務是否正在偵聽連接埠 80：
cstool -p 80 -h calserver ping http
依預設，cstool 會等待 120 秒，以查看有無回應；但您可以使用 -t timeout 選項變更該值。
如需完整的公用程式參照材料，請參閱 Calendar Server 指令行公用程式參照。
修正 start-cal 問題
如果發出 start-cal 時未能啟動所有的行事曆服務，則必須先將啟動的服務停止再重新啟動。例如，如果 enpd、csnotifyd 和 csadmind 啟動，而 cshttpd 沒有啟動，則必須停止 enpd、csnotifyd 和 csadmind。
若要啟動行事曆服務，請：
- 以對 Calendar Server 執行時所在的系統具有管理權限的使用者身份登入。
- 使用 start-cal 停止服務，然後再重新啟動服務。例如：
cal_svr_base/SUNWics5/cal/sbin/start-cal
start-cal 首先發出 stop-cal 指令，然後再啟動各種行事曆服務。
- 如果 stop-cal 未能將服務停止，則可能是因為某些子程序沒有停止。若要解決此問題，請參閱修正 stop-cal 問題。
修正 stop-cal 問題
Calendar Server 關閉時需要考量以下兩個不同的問題：
停止子程序
發出 stop-cal 後，很可能未停止某些子程序。例如，stop-cal 可能停止了 cshttpd 父程序，但未停止任何 cshttpd 子程序。在此情況下，您必須使用以下程序分別停止其餘 Calendar Server 程序：
- 以對 Calendar Server 執行時所在的系統具有管理權限的使用者身份登入。
- 透過為每種服務輸入 ps 指令，確定其餘 Calendar Server 程序的程序 ID (PID)：
ps -elf | grep cs-process
其中，cs-process 為 enpd、csnotifyd、csdwpd、csadmind 或 cshttpd。例如：
ps -elf | grep cshttpd
- 使用仍在執行的各程序的 PID，輸入 kill -15 指令終止該程序。例如：kill -15 9875
- 再次輸入各 ps 指令，確定所有 Calendar Server 程序均不再建議使用。
如果某個 Calendar Server 程序仍在執行，請輸入 kill -9 指令終止該程序。例 如：kill -9 9875
不正確關閉後回復
如果未正確關閉 Calendar Server，請執行以下步驟：
- 執行上一個程序 (停止子程序) 中的步驟。
- 手動刪除 LDAP 資料快取記憶體資料庫目錄中的所有檔案。這些剩餘檔案可能會損毀資料庫。若要刪除這些檔案，請：
- 重新啟動 Calendar Server。
cal_svr_base/SUNWics5/cal/sbin/start-cal
如需有關如何配置 LDAP 資料快取記憶體的說明，請參閱啟用 LDAP 資料快取記憶體。附錄 E「Calendar Server 配置參數」中包含用於配置 LDAP 資料快取記憶體的 ics.conf 參數清單。如需有關 LDAP 資料快取記憶體的更多資訊，請參閱「Sun Java System Communications Services 6 2005Q1 Deployment Planning Guide」。
無法連線至後端伺服器
如果您收到錯誤訊息，其中指出您前端伺服器無法建立與後端伺服器之間的連線，請嘗試執行以下步驟：
- 對後端伺服器執行 ping 作業以檢查它是否有回應。
如果有回應，請繼續步驟 2。如果沒有回應，請確定失敗原因。當後端伺服器再次運作時，請繼續步驟 3。
- 清除 CLD 快取記憶體。請參閱「清除 CLD 快取記憶體」。
如果您要使用 CLD 快取記憶體選項並已更新 ics.conf 參數的伺服器名稱，則應清除 CLD 快取記憶體以移除伺服器名稱。CLD 快取記憶體中的過期項目會妨礙前端伺服器建立與正確後端伺服器之間的連線，或會導致某個行事曆在被移動後，Calendar Server 無法找到該行事曆。
- 重新啟動 Calendar Server。
找不到行事曆
如果您要使用 CLD 快取記憶體選項並且已將一個或多個行事曆移至其他後端伺服器上 (或者變更了後端伺服器的名稱)，請執行以下步驟：
- 確定執行用於移動行事曆的程序，該程序位於：
- 清除 CLD 快取記憶體。請參閱「清除 CLD 快取記憶體」。
如果您將一個或多個行事曆移動至其他後端伺服器上，則 CLD 快取記憶體將會過期。若要更新 CLD 快取記憶體，您需要將其清除以便重建。
未正確完成的疑難排解搜尋
LDAP 目錄伺服器配置中的 nsslapd-sizelimit 與 nsLookthroughLimit 屬性的值必須足夠大，以使搜尋能正確完成。如果 nsSizeLimit 的值不夠大，可能會發生截斷，並且不會顯示任何結果。如果 nsLookthroughLimit 的值不夠大，搜尋可能無法完成。
本小節包含以下主題：
確定限制屬性是否有適當的值
將限制屬性設定為適當的值
這些屬性的 DN 為：
dn:cn=config,cn=ldbm databases,cn=plug ins,cn=config
從 csstored 關閉令人生厭的每日訊息
依預設，start-cal 指令啟動 csstored 程序 (即使其尚未配置)。未配置的 csstored 程序將在執行 csstored 的每台機器上每 24 小時發出一次訊息，說明其尚未配置。
若要停用該訊息，就應防止 csstored 在未配置的情況下執行。若要停止 csstored 程序執行，請為產生訊息的每台機器設定如下所示的 ics.conf 參數：
service.store.enable="no"
請小心不要將已配置 csstored 以進行自動備份的機器上的相應程序停用。
關於資料庫問題本小節包括關於 Calendar Server 資料庫的各種問題：
尋找 Berkeley 資料庫工具
您將要執行的許多疑難排解步驟要求已存取 Berkeley 資料庫公用程式。儘管 Calendar Server 隨附有這些公用程式的某個版本，但其不受支援。您可能要直接從 Sleepycat 軟體 (www.sleepycat.com) 中獲得更多資訊。
本小節包含以下主題：
存取 Berkeley 資料庫公用程式
設定並匯出 LD_LIBRARY_PATH 環境變數，以反應以下目錄：
cal_svr_base/SUNWics5/cal/tools/unsupported/bin/
可用工具清單
表 22-3 列出了一些常用 Berkeley 資料庫工具 (公用程式)。
偵測與修正資料庫死結
如果 Berkeley 資料庫處於死結狀態，則必須重設資料庫。儘早偵測此情況是很重要的。
若要使系統能定期檢查資料庫以偵測死結狀態並通知管理員，請：
偵測資料庫損毀
可導致行事曆資料庫損毀的原因有以下多種：系統資源競爭、硬體故障、應用程式錯誤、資料庫故障，當然，還有人為的錯誤。本小節說明如何偵測行事曆資料庫損毀：
資料庫損毀基本
沒人能保證資料庫不受到損毀。但是可以將資料丟失和作業當機時間降至最低。密切監視資料庫和行事曆伺服器是儘早偵測損毀的關鍵。經常並完整地備份是從損毀
(只要發現) 中恢復的關鍵。以下是行事曆資料庫可能受到的損毀的兩個層級：
監視記錄檔
監視 Calendar Server 記錄檔 (包括警示記錄)，以發現任何可能指出資料庫損毀的錯誤訊息。如需有關記錄檔的資訊，請參閱使用 Calendar Server 記錄檔。
您應定期檢查記錄檔，瞭解是否存在 ALERT、CRITICAL、ERROR 以及 WARNING 層級的錯誤，一旦發現錯誤，應執行 Calendar Server 來檢查事件，以找出可能的問題。Calendar Server 正常作業期間會產生 NOTICE 和 INFORMATION 層級的記錄事件，這些事件可協助您監視伺服器活動。
切勿移除資料庫目錄中的任何作業事件記錄檔。作業事件記錄檔包含作業事件更新 (增加、修改或刪除)，移除它們可能會損毀行事曆資料庫並且無法回復。
使用 csmonitor
使用 csmonitor 公用程式監視 Calendar Server。該公用程式會在偵測到問題 (例如存在多個作業事件記錄檔或行事曆資料庫磁碟空間不足) 時透過電子郵件警示管理員。如需更多資訊，請參閱 csmonitor。
檢查行事曆資料庫是否損毀
使用 check 指令掃描行事曆資料庫，以檢查行事曆中 (包括行事曆特性 [calprop]、事件和待辦事項 [工作]) 是否有損毀。如果 check 指令找到無法解決的不一致情況，它會在輸出中報告該情況。
check 指令不檢查警示或群組排程引擎 (GSE) 資料庫中是否有損毀。
若要檢查行事曆資料庫是否損毀，請：
- 以具有安裝 Calendar Server 的系統之管理權限的使用者身份登入。
- Calendar Server 可以執行，也可以停止；然而，如果可能，請停止 Calendar Server。
- 如果您尚未建立行事曆資料庫的複本，請建立複本。僅複製資料庫 (.db) 檔案。您無需複製任何共用 (__db.*) 檔案或記錄 (log.*) 檔案。
- 移至 cal_svr_base/SUNWics5/cal/sbin 目錄。例如，在 Solaris 作業系統上，輸入以下作為預設目錄：
cd /opt/SUNWics5/cal/sbin
- 在行事曆資料庫的複本中執行 check 指令：
./csdb check dbdir> /tmp/check.out 2>&1
如果您未指定 dbdir，check 將使用目前目錄中的資料庫。
check 指令可產生大量資訊，因此請考量將所有輸出 (包括 stdout 和 stderr) 重新導向至一個檔案 (如範例所示)。
- check 已完成時，請複查輸出檔案。如果您的資料庫發生損毀，請執行 rebuild 指令。(請參閱「重建已損毀的行事曆資料庫」。)
防止服務在資料庫發生損毀時中斷 (唯讀模式)
本小節包括如何在回復模式中保持已損毀的資料庫可存取，並包含以下主題：
使用唯讀模式
遇到資料庫損毀時，防止服務中斷的一個方法是將資料庫置於唯讀模式。此模式允許一般使用者讀取資料庫項目，但不允許對其進行增加、修改或刪除。如果一般使用者嘗試增加、修改或刪除任何行事曆資料，系統將提示錯誤訊息。此外，當資料庫處於唯讀模式時，增加、修改或刪除行事曆事件和待辦事項的管理員工具將不可用。
注意 如果資料庫損毀到不可被讀取的程度，則必須將服務中斷足夠長的時間以復原備份。復原備份的最快方法是具有完好的緊急備份。請參閱復原緊急備份。
將資料庫置於唯讀模式
處理常見資料庫故障
本小節包括一些常見資料庫故障以及一些建議的補救方法。本小節包含以下主題：
啟動期間 csadmind 不啟動或當機
由於 csadmind 是同時處理群組排程引擎 (GSE) 和警示派送引擎的服務，因此這種情況可能是由 GSE 佇列或警示佇列的違例項目導致的。
補救方法：
- 如果 csadmind 沒有執行，請立刻執行 stop-cal。
將行事曆伺服器置於執行狀態可能會導致作業事件記錄累積，從而進一步損毀資料庫，並且可能要花更長的時間使作業事件記錄檔符合資料庫。
- 嘗試再次重新啟動 csadmind (再次發出 start-cal)。
如果啟動成功，請確定透過以下操作使兩個佇列發揮其功能：
- 使用 csschedule 檢查 GSE 佇列。
- 使用 dbrig 檢查警示佇列。
如需有關執行 csschedule 與 dbrig 的說明，請參閱附錄 D「Calendar Server 指令行公用程式參照」。
- 如果 csadmind 由於傾印而當機，請分析 pstack。
如果您在追蹤中發現任何與 GSE 有關的功能 (它們中有字母 GSE)，請查看 GSE 佇列的第一個項目和事件資料庫中的參照項目。多數時候，GSE 項目中涉及的事件是違例項目。若要修正此問題，請：
- 使用 csschedule 移除 GSE 項目。
- 使用 cscomponents 從資料庫中移除違例事件。
如需有關執行 csschedule 與 cscomponents 的說明，請參閱附錄 D「Calendar Server 指令行公用程式參照」。
- 如果項目沒有被損毀，可能是行事曆伺服器無法處理的特殊情況。
執行以下步驟：
- 拍攝已損毀的資料庫的行事曆環境快照，並聯絡客戶支援。
若要建立環境備份，請：
─ 使用 db_checkpoint 公用程式，其位於：
cal_svr_base/SUNWics5/cal/tools/unsupported/bin/db_checkpoint─ 執行 db_archive -s，以識別所有資料庫檔案並將其複製到可移動的媒體 (例如 CD、DVD 或磁帶)。
─ 執行 db_archive -l，以識別所有記錄檔並將未套用的記錄檔複製到可移動的媒體裝置。
- 若要避免服務中斷，請實作以下步驟：
- 暫時將行事曆資料庫置於唯讀狀態。
在此狀態下，不允許增加、修改或刪除作業事件。一般使用者增加、修改或刪除任何行事曆資料時都會收到錯誤訊息。當資料庫處於唯讀模式時，增加、修改或刪除行事曆事件和待辦事項的管理員工具將不可用。
若要將行事曆資料庫置於唯讀模式，請編輯 ics.conf 檔案並將以下參數設定為 "yes"，如下所示：
caldb.berkeleydb.readonly="yes"
- 復原至緊急備份副本。
在 csstored 已配置並啟用的情況下，可用的緊急備份應為最新狀態。您應經常驗證緊急備份副本以確定其也未被損毀。(執行 db_verify。)
如需有關如何復原緊急備份副本的說明，請參閱復原緊急備份。
- 如果其他所有方法均失敗，請執行傾印和重新載入程序以查看其是否能挽救資料庫。
使用傾印和載入程序回復行事曆資料庫中說明了此程序。
服務當機並且一般使用者無法連線 ─ 孤立鎖定
這種情況可能是由控制執行緒導致的，該執行緒鎖定了 Berkeley DB 資料庫頁面，並在退出時未釋放鎖定。若要確認此問題，請執行 cshttpd 程序上的 pstack，並執行 csadmind。(pstack 是標準的 UNIX 公用程式，它位於：/usr/bin/pstack)。該公用程式將顯示等待以獲得鎖定的執行緒。
若要修正此問題，請重新啟動 Calendar Server，如下所示：
csdb rebuild 無法完成 ─ 資料庫迴路
資料庫迴路通常是由資料庫檔案中的損毀導致的。由於是資料庫損毀，故無法復原。有數個選項：
- 回復至緊急備份。
如果損毀是最近發生的，則可使用一個緊急備份。
- 使用突變歸檔回復程序。
如需建議程序，請參閱復原緊急備份。
- 使用傾印和重新載入程序 (使用傾印和載入程序回復行事曆資料庫)。
重建已損毀的行事曆資料庫
本小節說明如何使用 csdb rebuild 指令。本小節包含以下主題：
rebuild 簡介
rebuild 指令掃描行事曆資料庫，並檢查行事曆特性 (calprop) 事件和待辦事項 (工作) 是否損毀。如果 rebuild 指令找到不一致性，它會在 cal_svr_base/SUNWics5/cal/sbin/rebuild_db 目錄中產生重建行事曆資料庫 (.db 檔案)。
不帶有 -g 選項的 rebuild 指令重建除群組排程引擎 (GSE) 資料庫之外的所有資料庫。若還要重建 GSE 資料庫，請包含 -g 選項。
若要決定 GSE 資料庫是否有任何項目，請執行 csschedule -v list 指令，然後使 GSE 在您執行 rebuild 指令之前完成那些項目的處理。
重建行事曆資料庫
- 以具有安裝 Calendar Server 的系統之管理權限的使用者身份登入。
- 停止 Calendar Server。
- 建立行事曆資料庫副本，並將行事曆資料庫置於 /tmp/db 目錄。複製資料庫 (.db) 檔案和記錄 (log.*) 檔。您無需複製任何共用 (__db.*) 檔案。
- 移至 cal_svr_base/SUNWics5/cal/sbin 目錄。例如，在 Solaris 作業系統上，輸入以下作為預設目錄：
cd /opt/SUNWics5/cal/sbin
- 在行事曆資料庫的複本中執行 rebuild 指令：
./csdb rebuild /tmp/db /tmp/
如果未指定資料庫路徑，rebuild 將使用目前的目錄。/tmp/ 參數為重建資料庫指定目標目錄。
若還要重建 GSE 資料庫，請包含 -g 選項。
rebuild 指令可產生大量資訊，因此請考量將所有輸出 (包括 stdout 和 stderr) 重新導向至一個檔案。
- rebuild 已完成時，請複查 rebuild.out 檔案中的輸出。如果重建成功，rebuild.out 檔案中的最後一行應該是：
Calendar database has been rebuilt
- 驗證在先前步驟中的重建成功之後，請從 rebuild_db 目錄將重建資料庫 (.db) 檔案複製到您的生產資料庫。
- 如果您有任何損毀資料庫的共用 (__db.*) 檔案或記錄 (log.*) 檔案，請將其移至其他目錄。
- 重新啟動 Calendar Server。
重建輸出範例
以下範例顯示指令及其產生的輸出：
使用傾印和載入程序回復行事曆資料庫
本小節包含以下主題：
傾印和載入概況
使用傾印和載入程序以嘗試復原已損毀的資料庫。傾印和載入程序使用 Berkeley 資料庫 db_dump 和 db_load 公用程式，Calendar Server 在以下目錄中提供這些公用程式：
cal_svr_base/SUNWics5/cal/tools/unsupported/bin
db_dump 公用程式使用與 db_load 公用程式相容的格式，來讀取資料庫檔案並將資料庫項目寫入至輸出檔案。
如需有關 db_dump 和 db_load 公用程式的文件，請參閱 Sleepycat Software 網站：
http://www.sleepycat.com/docs/utility/index.html
您使用 db_dump 和 db_load 公用程式回復資料庫成功與否取決於您資料庫的損毀程度。在成功地回復資料庫之前，您可能需要嘗試多個 db_dump 選項。但是，如果您的資料庫嚴重損毀，回復也許是不可能的，您可能需要復原至資料庫的最後一個完好的緊急備份或歸檔檔案備份。
注意 在執行傾印和載入程序之前，行事曆資料庫必須為 Berkeley DB 3.2.9 版，或更高版本。如果您的版本是舊版本，請首先執行 cs5migrate 公用程式以對您的行事曆資料庫進行升級。
如需 cs5migrate 的最新版本，請致電 Sun 技術支援人員。
執行傾印和載入程序
- 以執行 Calendar Server 的使用者與群組身份登入，例如 icsuser 與 icsgroup，或以超級使用者 (root) 身份登入。
- 如有必要，請停止 Calendar Server。
- 使用一個公用程式 (例如 csbackup、Sun StorEdge Enterprise Backup™ 軟體或 Legato Networker® 備份損毀的資料庫。如需更多資訊，請參閱第 17 章「備份與復原 Calendar Server 資料」。
- 使用 db_dump 公用程式傾印每個已損毀的資料庫檔案。資料庫檔案包括 ics50calprops.db、ics50journals.db、ics50alarms.db、ics50events.db、ics50todos.db 和 ics50gse.db。
請依次使用以下選項執行 db_dump，直到已回復您的資料庫 (或直到您確定無法回復資料庫) 為止：
- 使用 db_load 公用程式將輸出檔案載入至新的資料庫檔案。例如：
db_load new.ics50events.db < ics50events.db.txt
如果 db_load 報告的鍵值或資料項目為奇數，請從步驟 4 開始編輯 db_dump 輸出檔案，並移除奇數鍵值或資料項目。然後再次執行 db_load。
- 使用 csdb rebuild 指令重建回復的資料庫檔案，如重建已損毀的行事曆資料庫中所說明。
rebuild 完成後，請複查輸出檔案中的輸出。如果重建成功，rebuild.out 檔案中的最後一行應該是：
Calendar database has been rebuilt
如果 csdb rebuild 指令失敗，請返回至步驟 4，並使用下一個 db_dump 選項 (-r 或 -R) 傾印您的資料庫。
如果 db_dump -R 選項未回復損毀的資料庫，請與 Sun Microsystems 技術支援代表或銷售客戶代表聯絡，以尋求援助。同時，您可能需要復原至您資料庫的最後一個完好備份。
復原自動備份副本
如果您已使用第 10 章「配置自動備份 (csstored)」中說明的自動備份功能，則當您的有效資料庫被損毀時，可以復原備份副本。
本小節包括如何復原兩種不同的自動備份：
復原之前
復原備份之前，請確定您已經完成以下作業：
復原緊急備份
當您的有效資料庫被損毀時，應首先選擇緊急備份。若要復原緊急備份，請執行以下步驟：
- 識別所有未套用的或開啟以備在已損毀的有效資料庫目錄中寫入的記錄檔。
- 關閉開啟以備寫入的記錄。它包含最新作業事件。
- 建立新的 (回復) 目錄。
- 將目前緊急備份副本複製到新的回復資料庫目錄中。
- 將已損毀的有效資料庫目錄中的 log.* 檔案複製到新的回復資料庫目錄中。
- 如果您保留了資料庫的歸檔檔案副本，請將尚未套用於有效資料庫的記錄複製到歸檔檔案目錄，這樣您的歸檔檔案備份副本就完整了。
- 將 db_recover 與為新的回復資料庫指定的 -c -h 選項一同執行。
例如，如果新的回復目錄叫做 recoverydb，則指令將如下所示：
db_recover -c -h recoverydb
- 將 log.* 檔案置於新的回復目錄中。
db_recover 程式將記錄檔套用於新的回復資料庫，但是從 4.2 版開始，Berkeley DB 要求保留這些記錄檔。
- 對新的回復目錄中的資料庫檔案執行 db_verify。
如需說明，請參閱檢查行事曆資料庫是否損毀。
- 對新的回復目錄執行 csdb -v list。
- 如果新的回復目錄通過了前面所有三個回復步驟，請用新的回復資料庫替代舊的已損毀的有效資料庫。
- 將新的有效資料庫複製到緊急備份目錄中，以作為新的快照執行。在拍攝下個常規快照之前，所有新記錄將被套用於此副本。
- 啟動 CalendarServer。
- 如果新的回復目錄在任何一個步驟中失敗，請按照如下說明識別未損毀的更舊的緊急備份：
復原歸檔檔案備份
如果您沒有未損毀的緊急備份，但有歸檔檔案備份及其作業事件記錄，則可以透過執行以下步驟復原已歸檔資料庫的最新未損毀版本：
- 識別所有未套用的或開啟以備在已損毀的有效資料庫目錄中寫入的記錄檔。
- 關閉開啟以備寫入的記錄。它包含最新作業事件。
- 建立新的 (回復) 目錄。
- 將最新的歸檔檔案副本及其記錄檔複製到新的回復資料庫目錄。
- 將已損毀的有效資料庫目錄中的任何未套用的 log.* 檔案複製到新的回復資料庫目錄中。
- 將 db_recover 與為新的回復資料庫指定的 -c -h 選項一同執行。
例如，如果新的回復目錄叫做 recoverydb，則指令將如下所示：
db_recover -c -h recoverydb
- 將 log.* 檔案置於新的回復目錄中。
db_recover 程式將記錄檔套用於新的回復資料庫，但是從 4.2 版開始，Berkeley DB 要求仍舊將這些記錄檔保留在此處。
- 對新的回復目錄中的資料庫檔案執行 db_verify。
如需說明，請參閱檢查行事曆資料庫是否損毀。
- 對新的回復目錄執行 csdb -v list。
- 如果新的回復目錄通過了前面所有三個回復步驟，請用新的回復資料庫替代舊的已損毀的有效資料庫。
- 將新的有效資料庫複製到緊急備份目錄中，以作為新的快照執行。
- 啟動 Calendar Server。
- 如果新的回復目錄在任何一個步驟中失敗，請按照如下說明識別未損毀的更舊的歸檔檔案備份：
修復自訂備份程序檔
本小節包含以下主題：
使用動態式庫編譯的 Berkeley 工具
如果您已使用 Berkeley 資料庫工具 (例如 db_recover) 建立了自訂備份程序檔，可能會發現升級至 Calendar Server 2004Q2 或更高版本後，該程序檔無法運行。其原因是：舊版 Calendar Server 使用靜態式庫編譯工具。現在是使用動態式庫 (libdb-4.2.so) 編譯工具。
修復自訂備份程序檔
若要將現有的自訂程序檔與新的動態式庫一同使用，請按如下所示設定以下全域變數：
LD_LIBRARY_PATH=libdb-4.2.so