Exchange Server 中的備份、還原和嚴重損壞修復
資料保護規劃是複雜的處理程序，需要您在部署的規劃階段進行許多決策。 在規劃過程中，請務必瞭解資料受保護的方式，以及判斷哪種方法最適合您組織的需求。
傳統上，下列情況會使用備份：
嚴重損壞 修復：在硬體或軟體失敗的情況下，DAG 中的多個資料庫副本可以啟用高可用性的快速容錯移轉，而且很少或無資料遺失。 如此就不會因為運作停擺而導致失去產能，這是從過去時間點備份復原到磁碟或磁帶時付出的重大代價。 DAG 可以延伸到數個站台，能夠從磁碟、伺服器、網路和資料中心故障情況中恢復。
復原 意外刪除的專案：過去，在使用者刪除了稍後需要復原之專案的情況下，它會尋找備份媒體（已儲存所需的資料），然後以某種方式取得所需的專案，並提供給使用者。 使用 Exchange 2019 Exchange 2016 中的 [可復原的專案] 資料夾，以及可以套用到該資料夾的保留原則，可在指定的時間內保留所有已刪除及修改的資料，因此復原這些專案會變得更輕鬆快捷。 這可讓一般使用者自行復原不小心刪除的項目，而減少 Exchange 系統管理員與 IT 服務台人員的負擔，也因此減少復原單一項目的複雜度與管理成本。 如需詳細資訊，請參閱Exchange Server 中的郵件原則和符合性，以及Exchange Server 中的資料遺失防護。
長期 資料儲存：備份也已做為封存，通常是用磁帶以長期快照的方式保留資料的時間點快照，以符合規範需求所制約。 Exchange Server 中的新封存、多信箱搜尋和郵件保留功能提供一種機制，可有效地以使用者可存取的方式，在長時間內保留資料。 這樣可避免從磁帶還原時付出的重大代價，因而提升產能。 如需詳細資訊，請參閱In-Place 封存 Exchange Server、 In-Place 中的 eDiscovery Exchange Server及 In-Place保留和訴訟暫止 Exchange Server。
時間點資料庫快照：如果您的組織需要一段時間內的信箱資料時點拷貝，Exchange 提供在 DAG 環境中建立延遲資料庫副本的能力。 在非常少見的情況下，儲存邏輯損毀會複寫到 DAG 中的多個資料庫副本，導致需要回到過去的時間點，此時這項功能就很有用。 如果系統管理員不小心刪除信箱或使用者資料，這也會很有幫助。 從遲延副本復原會比從備份復原更加快速，因為遲延副本不需要從備份伺服器複製到 Exchange 伺服器上，這是相當耗時的程序。 這可以藉由縮短停機時間來大幅降低擁有權總成本。
因為有原生 Exchange Server 功能可讓您以高效且經濟划算的方式，滿足上述每個案例，所以您可以減少或消除環境中傳統備份的使用。
Exchange 原生資料保護
Microsoft 的 Exchange Server 2016 和 Exchange Server 2019 的慣用架構，利用稱為 Exchange 原生資料保護的概念。 Exchange 原生資料保護依賴內建的 Exchange 功能來保護信箱資料，而不使用備份 (您仍然可以使用這些功能和建立備份)。 Exchange 2016 和 Exchange 2019 包含數個功能，當正確地部署及設定時，就能提供原生資料保護，而不需要對資料進行傳統備份。 使用 Exchange Server 內建的高可用性功能，可將停機時間和資料遺失降至最低，以防發生嚴重的事件，也會降低郵件系統的擁有權總成本。 透過結合這些功能與其他內建功能 (例如合法持有)，您可以減少或不必使用傳統時間點備份，並減少相關的成本。
除了判斷 Exchange Server 是否可讓您從傳統的時間點備份移開時，建議您評估目前備份基礎結構的成本。 當嘗試使用現有備份基礎結構從嚴重損壞還原時，請考量使用者停機和資料遺失的成本。 此外，也要包含硬體、安裝及授權成本，還有復原資料和維護備份的相關管理成本。 視組織的需求而定，使用至少三個信箱資料庫副本的純 Exchange 2016 或 Exchange 2019 環境很可能會比備份所提供的擁有權總成本低。
在使用 Exchange Server 內建的功能做為傳統備份的取代之前，您應該考慮幾個問題。 您的組織可能也有自身獨有的考量。 請考慮下列問題，並請注意這並非詳盡清單：
您應確認需要部署的資料庫副本數目。在取代傳統的資料庫保護形式 (例如獨立磁碟容錯陣列 (RAID) 或傳統 VSS 備份) 之前，強烈建議您至少部署三個信箱資料庫 (非延遲) 副本。
您應清楚定義復原時間目標與復原點目標，且您應證明將一組內建的功能結合使用來取代傳統的備份，能讓您達成這些目標。
您應決定每個資料庫需要多少副本，以涵蓋各種預定防護系統以避免發生的故障狀況。
您應判斷如果不考慮使用 DAG 或其某些成員，是否能夠獲得充足的費用支援傳統的備份解決方案。如果是的話，您應判斷該解決方案是否能改善您的復原時間目標或複原點目標服務等級協議 (SLA)。
您應判斷如果代管副本的 DAG 成員遇到故障，影響到副本或副本的完整性，您是否可負擔失去時間點副本造成的損失？
Exchange Server 可讓您部署更大的信箱，當兩個或多個高度可用的信箱資料庫副本) 時，建議的信箱資料庫大小上限為 2 tb (。 若採用大多數組織可能部署的大型信箱，您應判斷當啟用資料庫副本或延遲的資料庫副本時，如果您必須重現大量的記錄檔，您的復原點目標為何。
您應決定如何偵測主動資料庫副本的邏輯損毀，並防止該損毀複寫到資料庫的被動副本。這包括卻摁發生此情況時的復原計劃，以及過去發生此情況的頻率。如果您的組織常常發生邏輯損毀，則建議您使用一或多個遲延副本將該狀況的因素包含到您的設計中，並有足夠的重現延遲時間，讓您能夠在發生邏輯損毀時，且在損毀複寫到其他資料庫副本之前，便偵測到該邏輯損毀並採取動作。
成功完整或增量備份結束時要執行的功能之一，就是將資料庫復原時不再需要的交易記錄檔截斷。如果未執行備份，就不會截斷記錄檔。為避免記錄檔增長，您可以為複寫的資料庫啟用循環記錄。當您將循環記錄結合連續複寫時，便有了一種新的循環記錄，稱做連續複寫循環記錄 (CRCL)，這與 可延伸儲存引擎 (ESE) 循環記錄不同。不同於 ESE 循環記錄是由 Microsoft Exchange Information Store 服務來執行和管理，CRCL 則是由 Microsoft Exchange 複寫服務來執行和管理。啟用 ESE 循環記錄時，不會產生其他記錄檔，而是會在需要時，覆寫目前的記錄檔。然而，在連續複寫環境中，需要有記錄檔來傳送及重新顯示記錄。因此，當您啟用 CRCL 時，不會覆寫目前的記錄檔，並且會針對記錄傳送及重新顯示處理程序來產生關閉的記錄檔。
具體而言，Microsoft Exchange 複寫服務會管理 CRCL，以維護記錄的連續性，而且如果仍需要這些記錄來進行複寫，也不會將其刪除。Microsoft Exchange 複寫服務和 Microsoft Exchange Information Store 服務會使用遠端程序呼叫 (PRC) 通訊，以判斷可以刪除哪些記錄檔。
若要讓高可用性 (非延遲) 信箱資料庫副本執行截斷，下列條件必須成立：
記錄檔已備份或已啟用 CRCL。
記錄檔是在檢查點下方。
資料庫的其他非延遲副本同意刪除。
記錄檔已由所有延遲的資料庫副本進行檢查。
若要讓延遲信箱資料庫副本執行截斷，下列條件必須成立：
記錄檔是在檢查點下方。
記錄檔比 ReplayLagTime + TruncationLagTime 更舊。
記錄檔已在資料庫的主動副本上刪除。
支援的備份技術
Exchange Server 只支援 Exchange 感知的 VSS 備份。 Exchange Server 包含 Windows 伺服器備份的外掛程式，可讓您建立及還原 Exchange 資料的 VSS 型備份。 若要備份及還原 Exchange Server，您必須使用支援 vss 編寫器 Exchange Server 的 Exchange 感知應用程式，例如使用 vss 外掛程式 (的 Windows 伺服器備份) 、Microsoft System Center 2012-Data Protection Manager，或協力廠商 Exchange 識別 VSS 型應用程式。
如需如何使用 Windows Server Backup 備份和還原 Exchange 資料的詳細步驟，請參閱使用 Windows Server Backup 備份及還原 Exchange 資料。
Exchange Server VSS 編寫器
舊版的 Exchange 包含兩個 VSS 編寫器：一個位於 microsoft Exchange Information Store service 內 (store.exe) ，另一個位於 microsoft Exchange 複寫服務 (msexchangerepl.exe) 內。 回到 Exchange 2013，先前在 microsoft Exchange 資訊儲存庫服務中找到的 VSS 編寫器功能已經移至 microsoft Exchange 複寫服務。 這種架構在 Exchange 2016 和 Exchange 2019 中保持不變。 Exchange 感知 VSS 型應用程式會使用此編寫器（名為 Microsoft Exchange writer）來備份主動與被動資料庫副本，以及還原備份的資料庫副本。 雖然編寫器是在 Microsoft Exchange 複寫服務中執行，但需要有 Microsoft Exchange 資訊存放區服務才能執行，以宣告編寫器。 因此，需要兩個服務才能備份或還原 Exchange 資料庫。
Exchange Server 復原
幾乎所有的信箱伺服器及用戶端存取服務設定都儲存在 Active Directory 中。 如同舊版的 Exchange，Exchange 2016 和 Exchange 2019 包含安裝程式參數，用以復原遺失的伺服器。 這個參數 /m:RecoverServer 會使用儲存在 Active Directory 中的設定和設定資訊，重建並重新建立遺失的伺服器。 不過，請注意有幾項設定不會還原，例如對 web.config 和其他組態檔所做的變更。 此外，也不會還原自訂登錄項目。 建議您使用可靠的變更管理程序來追蹤和重新建立這些變更。
如需如何對遺失的 Exchange 伺服器執行伺服器復原的詳細步驟，請參閱Recover a Exchange Server。 如需如何復原屬於資料庫可用性群組成員之遺失伺服器的詳細步驟 (DAG) ，請參閱 復原資料庫可用性群組成員伺服器。
整合連絡人儲存復原
當您在 Exchange 2016 或 Exchange 2019 環境中使用 Microsoft Lync Server 2013 或商務用 Skype Server 2015 時，使用者的 Lync/商務用 Skype 連絡人資訊會儲存在使用者信箱中的特殊連絡人資料夾中。 這稱為整合連絡人儲存 (UCS)。 若還原 UCS 遷移的信箱，目標使用者的立即訊息連絡清單可能會受影響。 若使用者在上次備份後遷移，還原信箱將讓使用者的連絡清單完全遺失。 少數嚴重的情況下，上次備份由使用者修改的連絡清單將會遺失。 若要減這個輕潛在的資料遺失風險，請確認使用者在還原信箱前已遷移回立即訊息伺服器。
復原資料庫
復原資料庫是特殊種類的信箱資料庫，可讓您裝載還原的信箱資料庫，並在復原作業中從還原的資料庫擷取資料。您可以使用 New-MailboxRestoreRequest 指令程式從復原資料庫擷取資料。擷取完畢後，便可以匯出資料，或將資料合併至現有信箱中。復原資料庫可讓您從資料庫的備份或副本中復原資料，而不會干擾使用者存取目前的資料。
不支援使用任何舊版本的 Exchange 信箱資料庫作為復原資料庫。此外，用於資料合併與擷取作業的目標信箱必須與復原資料庫中裝載的資料庫位於同一個 Active Directory 樹系。
如需相關資訊，請參閱復原資料庫。如需如何建立復原資料庫的詳細步驟，請參閱建立復原資料庫。如需如何使用復原資料庫的詳細步驟，請參閱使用復原資料庫還原資料。
資料庫可攜性
資料庫可攜性是一項功能，可讓 Exchange 的信箱資料庫移至相同組織中任何其他 Exchange 信箱伺服器，並將該資料庫裝載到該資料庫。 使用資料庫可攜性可從復原處理程序移除幾個容易造成錯誤的手動步驟，從而改善可靠性。 此外，資料庫可攜性可減少各種失敗案例的整體復原時間。
如需使用資料庫可攜性的詳細步驟，請參閱使用資料庫可攜性移動信箱資料庫。
撥號音可攜性
撥號音可攜性是一種功能，可為影響信箱資料庫、伺服器或整個站台的失敗情況，提供有限的永續營運解決方案。 在還原或修復使用者的原始信箱期間，撥號音可攜性讓使用者有一個暫時信箱可用來傳送及接收電子郵件。 暫存信箱可以位於相同的 Exchange 信箱伺服器上，或組織中的任何其他 Exchange 信箱伺服器上。 這允許替代伺服器儲存先前位於無法再使用的伺服器上之使用者的信箱。 支援自動探索的用戶端 (例如 Microsoft Outlook) 會自動重新導向新的伺服器，而不需手動更新使用者的桌面設定檔。 在還原使用者的原始信箱資料之後，系統管理員可以將使用者已復原的信箱和使用者的撥號音信箱合併成最新的單一信箱。
使用撥號音可攜性的程序稱為「撥號音復原」。撥號音復原包括在信箱伺服器上建立空的資料庫，以取代失敗的資料庫。這個空的資料庫 (稱為「撥號音資料庫」) 可讓使用者在失敗的資料庫復原之前，傳送及接收電子郵件。在復原故障的資料庫後，撥號音資料庫與已復原的資料庫會交換，然後撥號音資料庫中的資料會合併到已復原的資料庫中。