DFSR 資料庫非預期關機引發 Event ID 2213，未觸發自動修復，求透過 WMI 手動觸發 DFSR Auto-Recovery 流程

Question

DFSR 資料庫非預期關機引發 Event ID 2213，未觸發自動修復，求透過 WMI 手動觸發 DFSR Auto-Recovery 流程

Kelvin Chan 60

我們一台執行 DFSR（分散式檔案系統複製）的伺服器在經歷突發性斷電後，系統記錄了 Event ID 2213（Dirty Shutdown）。根據微軟預設機制，DFSR 應在停用狀態下等待自動修復，但該伺服器在超過預設超時時間後，仍未自動發起資料庫自我修復與自我復原程序，導致相關複製群組（Replication Groups）持續處於停擺狀態。

我們希望透過 WMI 方法（WMI Methods）手動觸發 DFSR 資料庫的修復與 Resume 動作，以恢復資料同步。

想請教是否有驗證過的 PowerShell / WMI 標準作業流程可以：

呼叫 DfsrReplicatedFolderInfo 或 DfsVolumeConfig 相關的 WMI Method（如 ResumeReplication）來手動啟動復原程序？

針對此類 Dirty Shutdown 狀況，除了調整 StopReplicationOnAutoRecovery 登錄檔設定外，在執行 WMI 手動修復時有哪些需要特別注意的資料一致性檢查事項？

0 則留言

2 個回答

您的回答

Answer 1

您好，

在非正常關機（Dirty Shutdown）之後，Event ID 2213 的確可能會導致複寫群組保持非作用中狀態，尤其是在自動復原程序未正常觸發的情況下。在這種情況下，您可以透過 WMI 或 PowerShell 手動啟動復原程序。

Microsoft 支援的作法是透過 WMI 呼叫 DfsrReplicatedFolderInfo 或 DfsVolumeConfig 類別中的 ResumeReplication 方法。在 PowerShell 中，可以使用 Get-WmiObject 或 Get-CimInstance 連線至 DFSR 命名空間（root\MicrosoftDFS），然後呼叫該方法。此操作可有效恢復複寫，並讓 DFSR 重新建立資料庫。在執行之前，請務必確認您已備份最新的複寫資料，因為如果資料庫已嚴重損毀，手動介入可能會帶來資料一致性的風險。

進行手動修復時，請特別留意資料一致性檢查。確認 Staging 資料夾完整無誤、驗證 SYSVOL 或其他複寫資料夾是否處於健康狀態，並在恢復複寫後持續監控 DFSR 事件記錄。調整 StopReplicationOnAutoRecovery 登錄設定值，可以避免複寫長時間維持停用狀態，但應謹慎使用，避免造成其他預期外的影響。

至於停機時間的預估，修復程序本身通常很快完成，但如果需要在大型資料集上重新建立資料庫，所需時間可能長達數小時，實際時間取決於磁碟區大小以及目前累積的複寫待處理量。如果條件允許，建議先在非關鍵伺服器上進行測試，再套用至正式環境。

希望以上說明能對您有所幫助。如果您認為這個回答解決了您的問題，請點選「接受答案（Accept Answer）」，讓我知道這項回覆是否成功解答了您的疑問。

Jason.

Answer 2

Jason Nguyen Tran 29,785 獨立顧問

我想跟進確認一下，您的問題是否已經解決。如果您還需要更多資訊，歡迎隨時回覆。如果上述資訊對您有所幫助，歡迎點擊「Accept Answer」，幫助社群中的其他使用者找到解決方案。謝謝！

0 則留言