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