災難恢復

災難恢復，指自然或人為災害後，重新啓用信息系統的數據、硬件及軟件設備，恢復正常商業運作的過程。災難恢復規劃是涵蓋面更廣的業務連續規劃的一部分,其核心即對企業或機構的災難性風險做出評估、防範，特別是對關鍵性業務數據、流程予以及時記錄、備份、保護。

通過允許虛擬機在物理服務器之間進行無縫遷移，虛擬化提供了革命性的災難恢復計劃。 ^[1] 

在構建一個遠程VMware災難恢復站點之前，有許多問題需要考慮。

清查現有的基礎設施。在徹底理清一個主要數據中心的資產之前，不能對其進行復制。

瞭解應用程序和它們的依存關係。明確哪些應用程序需要抵抗災難的能力。要考慮到（主站點和備份站點）存儲和網絡架構之間任何潛在的差異，確保程序即使在不同的環境下，也能夠按照預期實現把故障轉移到備份站點。

建立恢復點目標（RPO）和恢復時間目標(RTO)。 如果數據每小時複製到第二數據中心，當災難發生時，有可能最多丟失之間59分59秒的數據。如果這樣是可接受的，不會嚴重地影響業務，那麼PTO可以設定為一個小時。

為用户服務。終端用户也許不能夠訪問運行維護的所有的服務器和應用程序。要考慮怎樣替換用户們的桌面和應用程序，明確他們怎樣進行遠程訪問。

選取數據中心地址。一條可承擔到主數據中心的高速連接是選擇災難恢復中心需要考慮的關鍵的幾個因素之一。

實施複製。初始化數據的複製將是最大規模的數據傳輸，隨後的對發生改變的塊進行復制將會小很多，但是複製數據的大小會依據應用程序中數據量改變的大小而定。複製的數據的大小也會依據複製的間隔（由RPO決定）而變化。 ^[2] 

硬件獨立：基於物理系統的災難恢復解決方案都需要將相同的硬件保留到恢復站點，或必須經過很多複雜耗時的步驟在新的或不同的硬件上重建服務器操作系統。有時候碰巧恢復服務器就是同一個硬件模型，但是包含了最新硬盤控制器固件，會導致服務器鏡像延遲。虛擬化使硬件從操作系統中抽象化，而且使操作系統中使用的設備驅動器統一化，不管是何種底層硬件模型，所有虛擬機都使用一個共同的驅動集。這樣，在新服務器上安裝服務器鏡像時就省了很多設備驅動對應的麻煩，大大減少了恢復時間和配置錯誤的風險。

虛擬機磁盤格式文件：虛擬機將其子操作系統、應用、存儲和配置（如IP地址）存放在一個文件裏。這個文件——虛擬機磁盤格式（VMDK）或虛擬硬盤（VHD）文件，包含了整個操作系統環境以便能進行簡單的虛擬機裝載和保存。這個文件不僅包含了操作系統鏡像和應用編碼，還描述了虛擬機所需的配置，其中包括虛擬處理器、內存和設備。這個簡單的可移動文件包含了組成服務器所需的一切信息、服務器環境描述、實際碼和數據。從虛擬機磁盤文件啓動虛擬機時系統會自動迅速設置所有參數。在災難恢復站點進行恢復會變得很簡單，只需啓動VMHD或VHD。

物理工具到虛擬工具：虛擬機解決方案需要利用管理工具來創建、啓動、停止和保存虛擬機鏡像。為了方便創建虛擬機，有很多工具可以幫助分析物理服務器和從服務器創建VMDK或VHD。從物理系統創建的VMDK或VHD文件可以很快地部署到恢復站點。

硬件再利用：恢復站點的虛擬機硬件不必閒置在那裏等着災難發生，它也可以用作開發、測試或其它用途。當發生災難時，關閉用於測試或開發的虛擬機，然後啓動生產虛擬機，這個過程只需幾秒鐘即可完成。 ^[3] 

由於用户對於服務器虛擬化技術接受程度不斷提高，業界有一種對於所謂的“萬能的高可用策略”的需求。雖然這種做法可以在一定程度上通過集羣故障遷移技術實現簡化數據保護的步驟，但並不是所有的數據保護都支持這種做法。

首先，即使當前關於服務器虛擬化部署最樂觀的預測成為現實，到2016年也仍然有21%的X86平台的關鍵業務（產生收入的高性能事務處理程序）運行在高達75%的沒有使用任何虛擬化技術的物理服務器上。所以，針對虛擬化和非虛擬化的不同服務器採用不同的策略是很有必要的。

在採用了 x86 虛擬化技術的工作負載中，一些虛擬機（VMs）和它們對應的數據盤（表現為VMDK 和 VHD 文件）相比其他虛機和數據盤次要一些。在沒有使用虛擬化技術的環境中存在很多不同的虛擬程序，但並不是所有的應用程序都是關鍵業務相關。傳統的服務器環境中，一些應用程序和虛擬機被頻繁使用，也有一些使用的不是那麼頻繁，這些現實情況都影響着數據備份和數據複製的頻率和策略。 ^[4] 

制定災難恢復計劃和構建基礎架構是一件讓IT經理煩惱的事。雲服務提供更低的成本和更大的靈活性,但並不是沒有風險的。

災難恢復即服務意味着更多的部署和靈活性測試,但也意味着更多的不確定性。

災難恢復(DR)會導致大量令人棘手的問題;災難恢復系統價格昂貴, 災難恢復配置難度較高,而且大多數災難恢復只能在非業務時間進行故障恢復測試，災難恢復模擬故障的內容很容易就過時了。災難恢復服務(DRaaS)是一種雲端容災的方法,成本更低,更容易部署,有定期提供測試計劃的能力,能與企業的變化保持同步。

值得注意的是,雲端的災難恢復選件可能在毀滅性的災難之後不可用。這意味着滯留IT資源和數據,使企業癱瘓。

數據中心工作人員和業務相關人員花了很多時間和精力在到制定和測試災難恢復腳本上。

首先,預測潛在的數據中心災難：災害性天氣,停電,供應商系統脱機,內部人員的破壞或外部攻擊都是有可能的。

確定公司的災難恢復應用程序要立即在線。審核清單和優先考慮日常運作的重點程序。

接下來, 原始資料和安裝冗餘數據中心基礎設施——服務器、軟件、網絡連接、支持應用程序的載體,。災難恢復計劃無法避免成本考慮;一個離線數據中心是昂貴的。

通常, 災難恢復計劃要求複製每個應用程序的基礎設施組件。此外, 災難恢復需要和主備份站點網絡連接，給備份系統當前的軟件信息。

適當的工作人員需要了解如何調用備份進程。他將決定哪些系統使用和哪些員工應該更換系統備份。災難恢復的職責包括通知他們的網絡和系統提供商更改的數據和確保員工知道如何恢復系統。理想情況下,業務用户只是略有影響。IT團隊需要在災難恢復數據期間提供最新的備份資料程序給工作人員。

IT部門經常花很多時間在設計和分析物理災難恢復計算環境上,而不是把時間用在編碼和測試中增加價值。測試一個災難恢復計劃,數據中心團隊要和相關的操作系統和所有最新的補丁一起測試需要,接收、框架、堆疊和安裝硬件。他們創建災難恢復用户帳户,部署框架或應用程序服務器環境和安裝測試工具。程序員可以花一半的時間在普通的災難恢復基礎設施問題上,而不是把時間用在實際的測試程序。

因為災難恢復過程複雜,企業通常一年一次或兩次進行測試偶發性的災難恢復計劃。公司越大,對災難恢復計劃證明過程越複雜。

一旦災難恢復程序進入計劃,他們很快變成過時。應用不斷變化,因此團隊必須在經常審查和更新災難恢復程序。大公司在計劃的每個細節上花費員工眾多的時間和高達7位數以上的金錢($1,000,000+)。災難恢復花費更多以確保計劃仍然是可行的。

許多企業只是口頭上承認災難恢復。在IT投資上，花大量的時間來緩解這1%,甚至更低的災難恢復風險似乎並不是個好的投資。IT經理有一份又長又不斷增長的日常優先清單,而當災難發生時，災難恢復是唯一重要的事。

雲服務在共享基礎設施上不斷省錢。雲的虛擬化和自動化的進步使之有更大的靈活性。企業根據需要使用雲資源,雖然只是在關鍵的應用上。暫時的案例中災難恢復測試發生容易增加。

基於雲端的災難恢復,程序員不用在比特和字節上苦幹;他們在硬件和操作系統界面上工作。因此更多的IT自動化的任務,生產力的提高和災難恢復測試時間的減少。數據中心的工作人員可以做為優先程序更經常, 分配更多的資源測試整個災難恢復服務功能。

雲端災難恢復服務的價格正在上升: 根據諮詢公司預測，從2013年的640,800,000美元漲到2018年的5,800,000,000美元,複合年增長率為55.2%。

災難恢復服務有其侷限性。

“雲端災難恢復供應商無法完備份系統冗餘,“劍橋公司的災難恢復分析師Rachel Dines説。

災難恢復供應商不能證明以模仿每個客户的基礎設施設置建設的數據中心成本, 所以他們走捷徑。災難恢復服務提供商將構建系統處理數量有限的故障。理論上講,如果遇到災難恢復特定場地的問題，比如數據中心的電力中斷，企業將災難恢復他們的系統,。然而,如果發生重大自然或人為災害,可能沒有足夠的空間在災難恢復站點運行每個災難恢復服務客户的應用程序。當發現當災難發生時， IT組織在危難關頭唯一能做的是找到它並解決,因為災難恢復服務比傳統的災難恢復構建有更大程度的風險。

雲端的災難恢復也增加了企業網絡帶寬的需求。在供應商的雲端災難恢復服務放置應用程序副本和虛擬機(VM)鏡像。那些應用程序和虛擬機鏡像不斷更新,來自企業生產站點與災難恢復服務供應商的數據中心的數據傳輸。這種加載應變可用帶寬。災難恢復服務能夠很好地處理簡單的應用程序,但可能降低網絡性能的進程密集型系統,如客户關係管理、企業資源規劃應用程序。 ^[5] 

對於企業——特別是自己運行虛擬桌面環境的企業——來説，確保部署可靠的災難恢復計劃是非常重要的。但是現在應該如何制定VDI災難恢復計劃？我們可以考慮Hyper-V、Windows To Go、存儲同步和離線虛擬桌面等四種方式。

第一種災難恢復方式不是很常用，但是據我所知已經至少有一家企業選擇使用這種災難恢復方式。這家企業在微軟Hyper-V平台當中運行自己的災難恢復虛擬桌面，並且將災難恢復虛擬桌面的備份版本存儲在雲中以防萬一。

對於大規模災難恢復事件來説，企業 通常會和硬件供應商達成協議，供應商將一批桌面PC租借給企業以供緊急使用，直到企業完全從事故當中恢復為止。根據協議，這些PC將會運行Windows 8並且已經安裝Hyper-V。企業的災難恢復計劃是將虛擬桌面的備份版本推送到所有PC上，使用Windows 8當中的Hyper-V功能為用户提供災難恢復虛擬桌面服務。

然而對於災難恢復大型企業來説，完成這項災難恢復計劃需要投入異常龐大的工作量，因此災難恢復可能是不切實際的，但是對於災難恢復中小型企業來説，災難恢復確實是一種十分高效的方式。這種災難恢復方式使得企業不再依賴於任何後台基礎架構，就能夠恢復虛擬桌面的正常運行。

唯一的要求是DHCP（動態主機配置協議）服務器可以為虛擬桌面分配IP地址。對於這種災難恢復情況來説，企業可以使用無線路由器提供到PC的網絡連接並且分配IP地址。

另外一種可行方案是Windows To Go的災難恢復。這種災難恢復特性在Windows 8當中被首次推出，災難恢復允許由USB閃存盤引導啓動Windows。

採用這種災難恢復方案的企業需要在遭遇災難襲擊之前，製作大量的USB閃存盤。將這些閃存盤存儲在遠離辦公地點的場所，在遭遇災難襲擊時分發給用户。

不幸的是，使用Windows 7的企業不能採用WindowsTo Go這種災難恢復方式，但是可以使用Boot to VHD作為替代災難恢復解決方案。

不論對於 哪種災難恢復情況，USB閃存盤的容量都將限制虛擬桌面鏡像的大小，因此，安裝有大量應用程序的桌面鏡像並不適合存放在USB閃存盤當中。

這種災難恢復方式的另外一種缺點是如果想要實現真正的高效恢復，就需要提前花費大量時間準備閃存盤。如果虛擬桌面鏡像版本十分穩定，那麼並不是什麼問題，但是如果企業需要定期更新其虛擬桌面鏡像，那麼這種災難恢復方式就變得不切合實際了。

另外一種在VDI災難恢復領域使用更為廣泛的方式是將現有環境構建在多個數據中心，或者災難恢復直接延伸到雲中，但是這種災難恢復方式是否可行在很大程度上取決於廠商的解決方案。雖然這是一種最為可靠的災難恢復方式，但是災難恢復也是最為昂貴的。

橫跨數據中心的基本理念是擴展虛擬桌面所在的主機集羣，以便能夠分佈在多個數據中心。同時將保存有虛擬硬盤的存儲設備複製到其他數據中心，使用這種災難恢復方式，可以將虛擬桌面同時存儲在兩個不同地點。

儘管理論上，可以實現將虛擬桌面故障轉移到第二數據中心，但是在第二數據中心創建一個完全分離的虛擬桌面池卻是一種更為高效的災難恢復方式；將虛擬桌面運行在其他位置也會產生網絡變更需求。

在一些災難恢復情況當中，相比於遠程恢復現有虛擬桌面，將用户連接到其他位置的虛擬桌面可能會更加容易一些。 ^[6] 

VMware提供的新特性允許移動辦公用户離線查看和使用虛擬桌面。理論上，企業可以使用這種災難恢復方式實現災難準備，以災難恢復應對能夠提前通知的、即將到來的災難，比如緩慢逼近的颶風。

但是這種災難恢復方式的缺點也十分明顯。首先，在災難已經出現之後採用這種災難恢復方式並不容易。其次，這種特性只能工作在VMware環境當中。

已經部署VDI環境的企業必須在災難恢復業務連續性計劃當中解決虛擬桌面問題。保證後端服務器資源在災難襲擊之後還能夠正常工作是最為基礎的部分，但是如果沒有虛擬桌面，用户就不能正常訪問這些資源。 ^[7] 

若處理得當，災難恢復（DR）計劃是一項複雜而耗時的任務，這有助於解釋為什麼在過去的幾年中，調查顯示有連續計劃的企業數量在下降。在一個年度普華永道（PricewaterhouseCoopers）的研究中，有災難恢復計劃的企業下降到約為39%，而同期的調查為50%左右。這些公司中，那些真正測試災難恢復計劃的企業通常是聲稱有計劃中的一小部分。這些只有災難恢復計劃文檔但是沒有實際測試的公司，其實際上對災難恢復的準備更加讓人擔憂。

由於對災難恢復必要性和實際價值的誤解，相關的計劃活動也少了。明顯的，雖然“更少（的員工）更高效的工作”就是“使用計算機來提高效率，”並且較少員工數量實際上更加依賴於自動化資源不間斷的使用以及減少（哪怕是短時間的）中斷操作帶來的誤差，但是這些見解和確保自動化的連續性和彈性的需求並沒有聯繫起來。 ^[8] 

評估災難恢復小組的能力的基本指標包括：知識，可以通過取得的專業證書或者參加的教育計劃獲得記錄；經驗，可以根據以前的工作職責或者參與實際的災難來判斷；積極性，可以根據參與專業機構、出席並且/或者在大型會議上演講以及發表的文章來判斷。每一項都可以被輕鬆地定義並制訂成基準，而且可以作為評估和增加災難恢復小組成員的技巧和技能的一個有效的出發點。 ^[9] 

IT專家們看到對於災難恢復（DR）的需求，並且很多人因為這個原因而使用OpenStack私有云。但是災難恢復投資回報（ROI）的模糊不清使得把這個推售到企業的業務部門成為很艱難的任務。

上週在亞特蘭大舉行的OpenStack峯會上的一次會議中，小組專家成員討論結果表明Swift存儲應用程序接口或者API，對於為災難恢復營造更好的環境尤為關鍵。

老化的基礎架構和過期的災難恢復計劃，與此同時還要遷移到24小時不間斷的運營模式，促使了，一家位於新澤西州Somerset的移動和存儲公司搭建了一個基於Swift的對象存儲環境。 ^[10]