容錯移轉和容錯回復
Azure Site Recovery 可讓您彈性地在發生災害時容錯移轉至 Azure，並在事件結束後容錯回復至內部部署機器。
您現在想要針對其他受保護環境進行完整的容錯移轉至 Azure。 您可以在單一測試虛擬機器上成功執行容錯移轉演練後，執行完整的容錯移轉。 您接著可以在容錯移轉成功完成後執行容錯回復。
在本單元中，您會探索容錯移轉和容錯回復之間的差異。 您也會了解如何在設定複寫至 Azure 的原則後，讓系統自動建立容錯回復原則。
容錯移轉和容錯回復
容錯移轉是在決定針對業務叫用 BCDR 計畫後所發生的流程。 容錯移轉會發生於使用受 Site Recovery 保護的目前即時環境移動至複本環境時。 此目標複本環境會取代即時環境，並成為主要的基礎結構。
容錯回復則是容錯移轉的相反。 前一個即時環境 (由於已進行容錯移轉，因此現在是複本環境) 會取得其原始角色，並再次成為即時環境。 在第一個執行個體上出現容錯移轉後，便需要發生重新保護階段。 在此階段中，您會讓原始環境回復成與新即時環境同步的狀態。 此流程可讓容錯移轉和容錯回復在不遺失任何資料的情況下發生。 重新保護階段可能會耗費相當長的時間，因為您需要確定舊的即時環境在災害之後正常運作。
容錯移轉和容錯回復動作的四個階段為：
- 容錯移轉至 Azure: 如果內部部署主要站台停機，則會做出要容錯移轉至 Azure (或是您次要站台) 的決定，並從主要複寫資料建立虛擬機器。
- 重新保護 Azure 虛擬機器: 發生容錯移轉之後，必須重新保護 Azure 虛擬機器，讓它們能在避開災害後將變更複寫回內部部署環境。 虛擬機器的電源會關閉以確保資料一致性。
- 容錯回復至內部部署: 當內部部署網站重新上線並執行時，便可能可以容錯回復至該環境。 它接著便會再次成為即時環境。 您無法容錯回復到實體伺服器。 所有系統都必須容錯回復至虛擬機器。
- 重新保護內部部署虛擬機器: 系統會重新保護內部部署虛擬機器，來使它們能在成功容錯回復之後開始複寫至 Azure。
容錯回復原則
當您建立內部部署複寫原則以將內部部署電腦複製到 Azure 時，系統會自動為您建立相關聯的容錯回復原則。 該原則有一些無法變更的固定屬性。 這些屬性包括：
- 只能複寫回您的內部部署設定伺服器。
- 復原點目標會設為 15 分鐘。
- 復原點保留期會設為 24 小時。
- 應用程式一致快照集會被設為每個小時。
執行容錯回復會停止 Azure VM。 在完成複寫後，請啟動您的內部部署 VM 來接管工作負載。 服務會中斷，因此請在不會影響您業務的時間排程容錯回復。
商務持續性和災害復原計畫
Site Recovery 的 BCDR 計畫允許自訂和排序虛擬機器的容錯移轉和容錯回復，以及在這些虛擬機器上執行的應用程式。 虛擬機器會被分組在一起，且可以使用指令碼來自動化容錯移轉或容錯回復期間的復原動作。 您也可以視需要為動作新增更多手動步驟。 若您在災害發生前測試 BCDR 計畫，您可以對正面的結果更有自信。 您必須讓您的基礎結構迅速地在次要位置啟動並執行，以符合公司的復原時間目標。
彈性容錯移轉
由於能夠彈性地進行容錯移轉，Site Recovery 可依需求針對測試目的執行容錯移轉。 隔離些測試代表它們不會中斷即時服務。 此彈性也能讓您在規劃中的即時服務中斷期間執行容錯移轉。 中斷不會打斷系統的使用者，因為他們會自動切換到複寫後的環境。 彈性也可以透過其他方式運作。 隨選容錯回復可以是所規劃測試的一部分，或是完整叫用災害復原案例的一部分。