災難恢復(DR)即服務，或者又稱為基于云的災難恢復，使得測試一個DR方案變得容易到幾乎可以忽略的地步。

與傳統的自主管理的有效業務連續性/災難恢復（BC/DR）規劃相反，災難恢復即服務或云計算災難恢復(DR)使得測試一個DR計劃變得容易到幾乎可以忽略的程度。

大多數業務連續性/災難恢復(BC/DR)規劃的一個主要障礙是必須進行重復性的測試，以此來確保當災難發生時系統的防備能力和證明符合有管理法規要求的組織的規范。將備用系統上線的復雜性，不僅僅造成測試任務本身的艱巨，更重要的是如果在沒有適當準備的前提下進行的話可能會影響到原本用戶正在使用的那些服務器。

當被問到DR測試的周期頻率時，ESG Research的回應是，在每周進行的從一次重大停電事故中能否順利恢復和恢復的速度有多快的測試來看，那些使用云災難恢復服務的組織的測試頻率是使用自主管理的BC/DR解決方案的測試頻率的4倍（20% 對比 5%）。這個測試頻率的對比結果源于幾個關鍵因素。

大部分服務提供商不僅僅提供“只支付您使用的”，有時候還包括一些折扣和免DR測試的特權。無論哪種方式，都只需要花最少的錢在后備的存儲資源上，然后只要在幾小時或者幾天的基礎上增加一點消耗的CPU資源，這使得測試變得經濟可行—而不是使用傳統的BC/DR服務提供商或者自主管理的BC/DR站點相關的更昂貴的流程。

現代的災難恢復即服務（DRaaS）解決方案通常包括“沙箱”的能力或者對虛擬機進行分區，這樣測試可以在不影響產品環境的條件下進行。典型的本地部署解決方案中通過傳統的虛擬化管理工具實現沙箱化通常會困難很多，然而大部分的DRaaS都提供這種被認為是“桌面上的利益”或者一個最基本的功能需求。

結合這些因素，非常坦率的說，故障轉移的防備性測試在大多數的DRaaS方案中簡單到必須要做，這恰恰和傳統的自主管理的BC/DR設施的測試限制完全相反。在另一方面來說，考慮到DRaaS的易于測試性，甚至可以制定一些讓每一個BC/DR方案都必須通過的測試基本要求。根據同樣的ESG Research的調查結果顯示，令人沮喪的是每年有15%的DRaaS和9%的自主管理的BC/DR方案沒有經過測試。

復制功能不是BC/DR解決方案

不管你是否更青睞DRaaS還是自主的BC/DR， 有一點需要注意的是，在你的存儲系統里的復制技術或者備份軟件并不是一個真正的BC/DR的解決方案。復制只是一種數據轉移技術，能夠提供給BC/DR方案所需要的IT資源。真正的BC/DR產品和功能包括對BC/DR計劃的制定開發，測試的編排，以及資源的故障轉移到備份站點的管理。BC/DR更多的是關于了解關鍵性系統故障對業務造成的影響，文檔化整個恢復的過程，進而影響到現有的關于測試和防備性的企業文化。也就是說，對于大部分企業組織，如果你沒有將數據和主要的系統進行復制，那么你的BC/DR計劃的其余部分就只是空談。

沒有測試，你只有BC/DR希望而沒有計劃

如果你沒有至少在每個季度測試每一個關鍵系統的恢復能力，那么請你開始這么做，否則你幾乎可以肯定的發現那些系統沒有你所想的那樣有彈性（當你最需要他們的時候）。對那些還在努力的維護著一個自主的BC/DR方案或者對此進行常規性測試的人，DRaaS也許就是最適合你的答案。

不管是自主的BC/DR還是DRaaS，最重要的是要記住***的BC/DR測試是那種會失敗的即使只是部分的，因為這樣你就知道哪些需要改進。如果你的BC/DR測試的結果是一概的全部通過，那么有兩種可能，你要么擁有一個被很好的部署和管理的當今市場上最***的BC/DR方案，或者（更多的可能是）你的測試還不夠徹底。

如果你不對你的BC/DR方案進行常規的測試，那么你就不算擁有一個BC/DR的規劃，你只有一個BC/DR的希望。隨著虛擬化技術將服務器變得便攜，使用DRaaS方案來提供備用站點很有成本效益，同時擁有編排服務恢復的可管理性，BC/DR不再只是一個希望或者一個計劃，而能夠真正變成任何規模的組織都能夠達成的目標。

原文出自：http://www.searchcloudcomputing.com.cn/showcontent_85977.htm