任何一個參與過災難恢復訓練的人對從無到有重建一個基礎設施要經歷的痛苦都很熟悉。重裝及修復應用程序服務器，讓支助性業務重現生機以及數據損壞或者丟失的可能性，一點點的細微差別都可能導致失敗。

由于虛擬化可以讓您使用已經擁有的系統——在生產中運行并且正常工作的系統，因此消除了建立一個新生產系統的不確定性。

盡管VMware的災難恢復工具工作得相當好，但如果您部署了Hyper-V，并希望在災難恢復計劃中使用微軟的虛擬機？

這也是可能的，如果您采取合適的步驟去實施行動計劃。

了解您的災難恢復方法

災難恢復計劃的第一步是搞清楚您的環境需求。是否您的組織有一個很短的恢復點目標(Recovery Point Objective RPO)——您的數據需要恢復到的恢復點——或者是否您上次的備份能滿足RPO的要求？

另外，您的恢復時間目標(Recovery Time Objective RTO) ——重新上線所花費的時間 ——會影響到您對基礎設備和專門軟件的需求。最有可能的是，您已經將您的應用程序“分層次”為多個恢復類，例如，第一層次為處理重要任務的服務器，可有可無的則為之下的第三層、第四層。

Hyper-V可以在所有的這些場景中得到支持，但這些場景里面的每一個以及它們的花銷都是非常不同的。

非關鍵服務器和冷站(后備站)

讓我們從最簡單的服務器開始——那些被認為不重要的或者有很長RPO或RTO的服務器。同時也包含一個基于冷站場景的計劃，在該場景中，您必須從頭開始重建服務器和網絡，并會依賴于冷站點恢復位置上的備份。

Hyper-V服務器可以通過一個主機服務器備份或者VM備份來進行恢復。恢復VM備份，除了主機被恢復后，所有的虛擬硬盤(VHD)以及VM 設置都會恢復到您之前備份時的樣子之外，和正常的機器恢復很類似。所有的VM都必須使用集成服務(Integration Services)，以便可以訪問卷影拷貝服務(Volume Shadow Copy Service VSS)，并使虛擬硬盤以一個一致的狀態來進行恢復。特定的應用程序，如微軟Exchange，因為可能會導致數據庫不一致，而不支持這種類型的備份。您可能需要使用可靠的恢復方法來處理這些應用程序。(請注意，即使是在恢復主機，您也需要重新配置您的網絡，所以有良好的文件是很必要的)

您的災難恢復計劃需要有一套用于轉移備份主機或者VM的有效腳本。確定如何去進行恢復，并在主機啟動前確定其存放的位置是很重要的。做完之后才去決定只會導致混亂和恢復的失敗。

關鍵服務器和積極的恢復目標

對于必須開啟，而且要保持開啟狀態的應用程序，在多個地方，轉為集群或者故障轉移負載平衡，是對要跨地域復制存儲的一個解決辦法。在存儲區域網絡(SAN)間復制是為了進行異地存儲，這種異地存儲可能會成為一個完整的遠程數據中心。當災難發生時，異地存儲會用于主機的恢復。

通過使用Hyper-V虛擬機，可以不像標準的物理服務器，使被復制后的存儲區域網絡中可以包含虛擬硬盤。這樣就可以進行故障轉移。簡單地將復制后的存儲區域網絡上線，并以很小的數據損失，將其中的虛擬硬盤加到主機配置中。再提醒一下，操作必須要小心，因為這會讓某些應用程序處于一個不穩定的狀態，并可能會需要進行真正的恢復或者用別的恢復方法來進行處理。

在Hyper-V R2中，可以通過GeoClusters使用集群共享卷(Cluster Shared Volumes CSV)。這讓您可以建立一個Hyper-V集群并讓其橫跨多個位置。雖然這樣做的好處是可以進行自動化的故障轉移，其缺點是太復雜并且需要特定的硬件。換句話說，您需要用一個服務器和存儲區域網絡設備匹配的溫備份站點(warm site)來做故障轉移。這個技術的關鍵是存儲是跨站點復制的。可是再次提醒，微軟沒有為這個存儲問題提供解決方案。幸運的是，SteelEye Technology、EMC以及其它廠商的產品解決了這個問題。

未來的云選項

微軟也許會作為支持無站災難恢復形式代表的Windows Azure，很可能是即將可用的另外一個選擇之一。

雖然現在已經可以將虛擬硬盤移到Azure云里，其它的一些問題，例如私有網絡和恢復時間仍在發展中。在未來，盡管您可能不能對整個基礎設施進行復制，但時間會證明，Windows Azure對像網站和SQL Server數據庫這樣的數據中心的特定設備是有價值的。

總的來說，盡管微軟Hyper-V的災難恢復解決方案還沒有達到VMware的級別，但不要忘了，在VMware的恢復解決方案中也有相當多的腳本。災難恢復——即使是一個低成本的計劃——可以在少量的測試和對您需求很好理解的基礎上開發出來。但前提是，要熟悉您可以有哪些選擇，因為知道如何管理現有的Hyper-V環境，并基于RTO和RPO目標做出正確的規劃對成功的恢復是至關重要的。