在一個數據中心里，某個地方發生了火災，并迅速蔓延到了距離服務器只有幾個房間的地方。盡管數據中心的消防部門在不到10鐘內撲滅了火災，服務器安然無恙。但是冷卻和電力等基礎設施卻被全部損壞，甚至一些連接到服務器的線路也受到波及。在接下來的幾個星期里，這個數據中心都不能正常的工作。

[[16152]]

于是，在接下來的時候，由于沒有服務器能夠工作，無法正常的和客戶聯系，這意味著企業將的業務會受到嚴重的影響。而在IT部門，似乎沒人知道如何讓備份的系統以及應用程序工作。可能首席技術官知道，但災備計劃是幾年前完成的，他也不清楚其中的細節。而制定那個計劃的人卻在西藏登山，通過電話和電子郵件顯然不能夠讓數據中心更好的恢復正常工作。

這并不是一個不著邊際的假設，而是一個隨時可能發生的情況。由此可見，建立一個完整的災備計劃并認真的執行是多么的重要。即使出現了最壞的的情況，企業的服務器也能夠快速的恢復正常運行。#p#

確定優先級

由于應用程序和數據的重要性的不同，因此災備計劃應該考慮在災難發生的時候哪些應該優先得到恢復。在規劃災備計劃的同時應該選擇那些優先恢復的服務器，來盡量減少客戶等待的時間。如果有10臺服務器，可能有3臺服務器上運行著關鍵性的任務，需要24小時運行。但有些服務器就不太重要，即使關掉幾天，對企業的業務也不會產生什么影響。

而劃分這個優先順序也包括收集除了IT部門以外其他部門的服務器使用狀況。即使IT部門以及客戶的服務器全部恢復了正常，但收發郵件的服務器卻沒能恢復工作，那么其他部門也不能正常工作，甚至會直接影響到企業的管理。

另外，即使有了完整的災備計劃，如果不能很好的執行也沒什么用。如果只有一個人了解這個計劃，如果出現問題的時候他不在，這顯然是個很悲劇的事情。所以災備計劃應該存放在硬盤里或者打印出來，并讓相關的人員知道。而出現問題的時候，工作人員也應該知道該和誰聯系，來確保在最短的時間內讓數據中心恢復正常的工作。#p#

仔細規劃

災備計劃的規劃是一個持續的，不斷演進的過程，制訂好了災備計劃就等著災難的發生是一個顯然錯誤的觀念。

雖然管理員在不斷的評估數據中心網絡容量的需求，但不要忘了災備計劃也占其中的一部分，要留給備份所需的空間。這并不是一個可選部分，而是一個必要的部分。因為包含了數據和應用程序的備份計劃，在災難發生的時候就會顯示出它的價值，快速的幫助企業恢復業務是花多少錢也買不來的。

整個計劃還包括遠程戰略。當發生災難的時候，必須要確保管理員在異地也能啟動災備計劃。而發生災難的時候，太多的人參與計劃反而起不到積極的作用。在這個領域，不會需要太多的幫助，有時候反而會導致更糟的事情發生。

所以災備計劃應該確定哪些人分別負責哪些工作。并且讓工作人員們清楚，什么是應該做的，什么不應該做。#p#

不要忘了企業

由于管理員在選擇災備計劃的時候往往從技術方面來考慮，他可能忘了，災備計劃的規劃首先必須服從于企業的業務需求。在今天，雖然IT的基礎設施隨著虛擬化，云計算技術的發展，結構發生了很大的變化。但是，業務的連續性和災難恢復的聯系依然是密不可分的。

規劃災備計劃的根本原則并不是技術的可行性，而是那些業務所依賴的服務。畢竟，數據中心也是為了更好的為企業提供服務。不僅僅的企業數據中心，云計算服務提供商，托管服務提供商都必須要有良好的業務連續性，并讓它的客戶清楚的知道。才能保證他的優勢。

因此，盡管災難恢復解決方案在不斷的發展，但最根本的災備計劃仍然是一致的。保證業務的連續性也是制定災備計劃的根本意義所在，也是最大限度的提高災難恢復效率的唯一出發點。