Exchange Server中的備份、還原和災害復原
資料保護規劃是複雜的處理程序，需要您在部署的規劃階段進行許多決策。 在規劃過程中，請務必瞭解可保護資料的方式，並判斷哪一種方法最符合貴組織的需求。
傳統上，下列情況會使用備份：
災害復原：在發生硬體或軟體失敗時，DAG 中的多個資料庫複本會啟用高可用性，並快速容錯移轉，且幾乎不會遺失資料。 如此就不會因為運作停擺而導致失去產能，這是從過去時間點備份復原到磁碟或磁帶時付出的重大代價。 DAG 可以延伸到數個站台，能夠從磁碟、伺服器、網路和資料中心故障情況中恢復。
意外刪除專案的復原：在過去，在使用者刪除稍後需要復原的專案的情況下，它會涉及尋找儲存需要復原之資料的備份媒體，然後以某種方式取得所需的專案並提供給使用者。 有了 Exchange 2016 和 Exchange 2019 中的 [可復原的專案] 資料夾，以及可套用的保留原則，就可以將所有已刪除和修改的資料保留一段指定的時間，讓這些專案的復原變得更容易且更快。 這可讓一般使用者自行復原不小心刪除的項目，而減少 Exchange 系統管理員與 IT 服務台人員的負擔，也因此減少復原單一項目的複雜度與管理成本。 如需詳細資訊，請參閱Exchange Server 中的傳訊原則和合規性，以及Exchange Server 中的資料外泄防護。
長期資料存儲器：備份也已當做封存使用，而且通常會使用磁帶來保留資料的時間點快照集，以長期受合規性需求規範。 Exchange Server中新的封存、多信箱搜尋和郵件保留功能，可提供一種機制，以使用者可存取的方式有效率地長期保留資料。 這樣可避免從磁帶還原時付出的重大代價，因而提升產能。 如需詳細資訊，請參閱Exchange Server中的就地封存、Exchange Server中的就地電子檔探索，以及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 Server 備份的外掛程式，可讓您建立和還原 Exchange 資料的 VSS 型備份。 若要備份和還原Exchange Server，您必須使用支援 VSS 寫入器的 Exchange 感知應用程式Exchange Server，例如搭配 VSS 外掛程式) 的 Windows Server Backup (、Microsoft System Center 2012 - Data Protection Manager 或協力廠商 Exchange 感知 VSS 型應用程式。
如需如何使用 Windows Server Backup 備份和還原 Exchange 資料的詳細步驟，請參閱使用 Windows Server Backup 備份及還原 Exchange 資料。
Exchange Server VSS 寫入器
舊版 Exchange 包含兩個 VSS 寫入器：一個位於 Microsoft Exchange 資訊存放區服務 (store.exe) 內，另一個位於 Microsoft Exchange 複寫服務 (msexchangerepl.exe) 內。 回到 Exchange 2013，先前在 Microsoft Exchange 資訊存放區服務中找到的 VSS 寫入器功能已移至 Microsoft Exchange 複寫服務。 此架構在 Exchange 2016 和 Exchange 2019 中保持不變。 這個名為 Microsoft Exchange 寫入器的寫入器是由 Exchange 感知 VSS 型應用程式用來備份主動和被動資料庫複本，以及還原備份的資料庫複本。 雖然寫入器是在 Microsoft Exchange 複寫服務中執行，但需要執行 Microsoft Exchange 資訊存放區服務，才能公告寫入器。 因此，需要兩個服務才能備份或還原 Exchange 資料庫。
Exchange Server 復原
信箱伺服器和用戶端存取服務的幾乎所有組態設定都會儲存在 Active Directory 中。 如同舊版 Exchange，Exchange 2016 和 Exchange 2019 包含安裝程式參數，以復原遺失的伺服器。 此參數 /m：RecoverServer可用來重建並重新建立遺失的伺服器，方法是使用儲存在 Active Directory 中的設定和組態資訊。 不過，請注意有幾項設定不會還原，例如對 web.config 和其他組態檔所做的變更。 此外，也不會還原自訂登錄項目。 建議您使用可靠的變更管理程序來追蹤和重新建立這些變更。
如需如何執行遺失 Exchange 伺服器之伺服器復原的詳細步驟，請參閱復原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) 會自動重新導向新的伺服器，而不需手動更新使用者的桌面設定檔。 在還原使用者的原始信箱資料之後，系統管理員可以將使用者已復原的信箱和使用者的撥號音信箱合併成最新的單一信箱。
使用撥號音可攜性的程序稱為「撥號音復原」。 撥號音復原包括在信箱伺服器上建立空的資料庫，以取代失敗的資料庫。 這個空的資料庫 (稱為「撥號音資料庫」) 可讓使用者在失敗的資料庫復原之前，傳送及接收電子郵件。 在復原故障的資料庫後，撥號音資料庫與已復原的資料庫會交換，然後撥號音資料庫中的資料會合併到已復原的資料庫中。