第一篇：政府行業系統災備建設白皮書

政府行業系統災備建設白皮書

目 錄

政府行業災備建設特點及案例剖析..............................................69 6.1

政府行業災備建設特點及案例剖析...........................................................69 6.1.1

行業概覽..............................................................69 6.1.2

行業現狀與需求........................................................72 6.1.3

應用場景與解決方案....................................................74 6.1.4

典型用戶案例..........................................................78 6.1.5 小結...............................................................80

災備市場與行業趨勢...................................................................137 7.1

災備市場概況........................................................................................137 7.1.1

市場高速增長.........................................................137 7.1.2

市場多元發展.........................................................138 7.2 未來五年（2020-2025）趨勢...............................................................139 7.2.1

信創推動核心技術自主研發.............................................139 7.2.2

合規性仍是推動行業發展主因...........................................140 7.2.3

平臺化推進災備產業化發展.............................................141 7.2.4

災備人才和用戶群體持續增長...........................................142

政府行業災備建設特點及案例剖析 數字化轉型加速了行業的信息化建設，如何保障信息化建設安全，國家已經從法律層面制定了一系列的法規條文，并明確了信息運營主體的職責。在這個大背景下，災備建設落實到具體的建設工具，無外乎數據的容災備份、遷移、恢復等技術產品。但每個行業的信息系統和數據特點不同，也造就了不同的災備解決方案。譬如，政務行業的私有云架構，不僅要考慮內外網特殊情況，還要考慮數據中心建設一期和二期軟硬件的異構問題等。

為了更真實地展現重點行業的災備建設特點，本章節涉及的行業概述、應用場景和典型案例，主要來自英方軟件近百位一線技術工程師的實踐。這些內容幾乎全面覆蓋了各個行業的災備特點和需求，在具體的應用場景和方案剖析中，也可以作為大家參考的重要的實踐內容。

本章節共列舉了政府、金融、醫療、教育、電信、能源、制造等行業的災備建設特點，這些行業所涉及的內容如下表所示。

行業 內容 政府 指各級政府部門及各種機構，如公檢法、公積金、大數據局、環保、消防等部門。

金融 指經營金融商品的特殊行業，包括銀行、保險、信托、證券、會計、審核及相關設 備制造商、系統集成商。

醫療 指與人們身心健康相關的產業的統稱，包含了傳統意義上的衛健委機構、醫院等。

教育 指各地教育局和各大中專院校及中小學等教學主體。

電信 指各個電信運營商以及運營商機構依托各地 IDC 進行的云災備建設。

能源 指天然氣、石油石化、國家電網、南方電網及各地下屬電網公司等。

制造 指機械和電子制造業、輕紡工業、資源加工工業，如航空發動機、半導體芯片、機械、汽車、五金、食品、服裝等。

表 6-1 災備重點行業涉及領域 6.1 政府行業災備建設特點及案例剖析 6.1.1 行業概覽 電子政務是指政府機構通過運用信息化手段，實現辦公自動化、24 小時咨詢服務、網上申報和審批等各種政府職能。電子政務應用包括政務信息查詢、公共政務辦公、政府辦公自動化等。本內容涉及的電子政務的建設主體是各級政府部門及各種組織機構，涵蓋各級黨組織、政府部門、公檢法、委辦機構等，譬如各級人民政府、人民檢察院、人民法院、公安部門、消防、工商、稅務、環保等。本章節所涉及的電子政務的數據安全和業務連續性的內容，也是以為百姓提供日常服務的政府及組織為主。

新基建、數字中國、智慧城市、互聯網 + 政務等新型城市的建設浪潮，都離不開作為電子政務底座的新型基礎設施—政務云。當前，各地政府大力興建的政務云，也不負重托，通過新型電子政務的方式，在數字政府、智慧政務、智慧民生等應用領域，逐步實現人民政府提出的“讓數據多跑路，讓百姓少跑腿”的鄭重承諾。為此，通過先進的數據復制、容災備份等技術構建一個安全可靠的政

務云，已經成為各級政府組織信息化建設的重要內容之一，也是建設人民滿意的數字化服務型政府的必要條件。

（1）等級保護和分級保護 政府電子政務的建設和發展關乎國計民生，也關于國家安全和經濟發展。由于當前的信息安全保密問題日益突出，勒索病毒、網絡攻擊、機密文件泄露等事件愈發頻繁，給國家安全和政府外交工作帶來重大的挑戰。為此構建新時代電子政務的信息化應用，必須做好關鍵信息和數據的安全管理及保護工作，必須加強對政府信息數據和國家機密保護的宣傳工作，必須確保各類信息不泄露、不丟失和重要系統不出現重大故障。

強化信息安全，法度利器先行。國家層面已制定了相應的一系列法律法規，強制性要求各類數據中心的運營機構必須遵守各項信息安全規定，提升整體的信息安全防護措施，而政府及組織在這方面起到了帶頭示范的作用。在國家已頒布的一系列法律法規中，等級保護和分級保護的影響范圍最廣。

等級保護，即信息安全技術網絡安全等級保護要求，是我國信息安全保障的一項基本制度。2003 年由中辦、國辦轉發《國家信息化領導小組關于加強信息安全保障工作的意見》，正式提出實行信息安全等級保護和建立國家信息安全保障體系的明確要求。2007 年和 2008 年頒布實施的 《信息安全等級保護管理辦法》和《信息安全等級保護基本要求》，統稱“等保 1.0 ”；2019 年 5 月發 布《信息安全技術網絡安全等級保護基本要求》，統稱“等保 2.0 ”。在等級保護分級中，按重要程度共分為五級：

一級（自主保護）

二級（指導保護）

三級（監督保護）

四級（強制保護）

五級（專控保護）

除了等級保護，國家也對涉及國家機密的信息系統進行了分級。2005 年 12 月，國家保密局下 發了《涉及國家秘密的信息系統分級保護管理辦法》，同時，《保密法》修訂草案也增加了網絡安全保密管理的條款。分級保護分為：

秘密級 機密級和機密級（增強）

絕密級 等級保護和分級保護的制定，從國家法律層面規范了公民、法人和機構組織對信息系統分等級 實行安全保護。各級政府電子政務的建設，涵蓋幾十個不同等級的應用系統，如何區分這些系統的等級和分級，政府政務管理機構已經組織專家團隊做了全面的評估和評定，對政府應用的系統進行了等級劃分。

一般而言，面向社會提供服務窗口的網站及 Web 應用系統對國家安全影響有限，可以劃分為一二級等級保護，對外公開的氣候、經濟統計、災害預防等信息也不屬于國家秘密。但是，一些重要的網站、內部流轉的機密公文及測繪、國防等信息系統，就屬于較高等級或秘密的保護范疇。故從數據管理和災備角度分析，電子政務信息系統應根據其信息安全保護等級和業務連續性要求，選擇建設相對應的災備系統，以防止因系統終止提供服務而對市民的正常生產生活帶來影響，甚至造成嚴重的社會影響；電子政務信息系統也應根據其數據的重要性程度制定數據備份策略，以防止因數據丟失而造成損失。

（2）政府電子政務發展的法律法規 國家在大力推進電子政務快速發展的同時，不同主管機構和部門下發和頒布了一系列的政策法規。例如：

《中華人民共和國網絡安全法》第七十二條規定：國家機關政務網絡的運營者不履行本法規定的網絡安全保護義務的，由其上級機關或者有關機關責令改正；對直接負責的主管人員和其他直接責任人員依法給予處分。

《國務院辦公廳關于印發進一步深化“互聯網+ 政務服務”推進政務服務“一網、一門、一次” 改革實施方案的通知》（國辦發〔2018〕45 號）要求“加強數據共享安全保障”，依法加強隱私等信息保護；提高國家電子政務外網、國家數據共享交換平臺和國家政務服務平臺的安全防護能力； 推進政務信息資源共享風險評估和安全審查，強化應急預案管理，切實做好數據安全事件的應急處置。

《國家發展改革委關于印發“十三五”國家政務信息化工程建設規劃的通知》指出，“構建一體化政務數據平臺”是規劃的主要任務之一，即按照“數、云、網、端”融合創新趨勢及電子政務集約化建設需求，依托統一的國家電子政務網絡加快建設綜合性公共基礎設施平臺，形成互聯互通、安全防護、共享交換、云計算、數據分析、容災備份等綜合服務能力，實現電子政務關鍵公共基礎設施的統建共用，支撐政務業務協同和數據共享匯聚。

本章節整理了對政府電子政務發展起到積極推動作用的法律法規及文件，各級政府及組織可根據機構規模、屬性、等級進行相應的數據安全和業務連續性的建設。

“加快電子政務信息系統的發展” 《國務院辦公廳關于促進電子政務協調發展的指導意見》（國辦發〔2014〕66 號）

《國務院關于促進云計算創新發展培育信息產業新業態的意見》（國發〔2015〕 5 號）

《國務院關于印發政務信息資源共享管理暫行辦法的通知》（國發〔2016〕51 號）

《國務院關于加快推進“互聯網 + 政務服務”工作的指導意見》（國發〔2016〕55 號）

《國務院辦公廳關于印發 <2017 年政務公開工作要點 > 的通知》（國辦發〔2017〕24 號）

《國務院辦公廳關于印發政府網站發展指引的通知》（國辦發〔2017〕47 號）

《國務院辦公廳關于印發< 政府網站集約化試點工作方案> 的通知》（國辦函〔2018〕71 號）

“關于保障電子政務信息系統安全的發展” 《關于加強黨政部門云計算服務網絡安全管理的意見》（中網辦發文〔2014〕14 號）

《關于加強黨政機關網站安全管理的通知》（中網辦發文〔2014〕1 號）

《公共安全業務連續性管理體系指南》國家標準（GB/T 31595-2015）

《國家網絡空間安全戰略》（國家網信辦 2016 年 7 月）

《中華人民共和國網絡安全法》（2017 年 6 月 1 日）

《信息安全技術網絡安全等級保護基本要求》（GB/T 22239-2019）

《網絡安全審查辦法》（國家網信辦 2020 年 4 月）

隨著我國經濟體量的持續壯大和國際地位的顯著提升，境外敵對勢力通過網絡滲透攻擊我國重要部門的網絡系統，以及通過黑客技術加密重要文件的事情時有發生。據新聞報道，從 2014 年開始，某機構安全大腦通過整合海量安全大數據，發現了多起境外 APT 組織使用“在野”0day 漏洞針對 我國境內目標發起的 APT 攻擊，并發現境外針對中國境內目標的攻擊最早可以追溯到 2007 年，至 少影響了中國境內超過萬臺電腦，攻擊范圍遍布國內 31 個省級行政區。

這些攻擊對象包括國防、航天、政府、重要企業的網絡系統，由此可見各級政府及組織加強電子政務信息系統和數據安全的保護迫在眉睫。

6.1.2 行業現狀與需求 提高工作效率，建設人民滿意的數字化服務型政府，離不開政務電子化所需要的各種信息化技術和設備。我國電子政務建設，以 1999 年政府上網工程啟動這一標志性事件為界 , 之前為政府信息化的前期 , 之后為政府信息化大規模建設階段。我們總體上將其劃分為三個時期：

（1）網站建設時期 這一時期的電子政務建設，更多關注政務信息和流程的公布，與群眾線上交互等。同時，通過政府部門的帶動，培養群眾對新技術、新方式的接受和適應能力。

（2）信息化時期 這個時期主要是在第一階段的基礎上，實現協同辦公、不見面審批、網上執法、網絡化管理等。這個階段所面臨的挑戰是實現孤立部門間流程的統一和協同化。

（3）大數據時代 這個階段政府的網絡建設觀念逐漸淡化，更多強調對大數據、人工智能、容器云、區塊鏈等新興技術的應用，實現對數據的挖掘、交互、分析、保護，同時也更強調數據和業務的安全性，強調部門協同打破數據孤島，保障數據價值的時效性，加快數據流動，最終為供給側提供需要的數據價值，從而為老百姓提供更高效便捷的政務服務。

時至今日，電子政務也從前端網站建設轉向基礎設施集約建設，政務云和大數據中心已成為數字政府建設的當務之急。政務云也是電子政務 IT 發展新 10 年，在云計算時代，電子政務 IT 基礎

設施將從分離重新走向融合，用戶通過云操作系統，將數據中心多廠家異構的計算、存儲、網絡資源進行統一融合，對外提供開放與標準化的IT 服務接口，實現數據資源與應用資源的融合。為此，在眾多的子系統與數據庫中，需要一個平臺來傳遞可靠的、與平臺及語言無關的數據，且能夠把數據透明化。這時，數據復制技術將在接口調用過程中發揮重要作用，通過不斷的收集、調用、分析數據，滿足 IT 業務的需求，并協助業務模型決策做出更智能的預測。

硬幣都有兩面性，云環境下的電子政務在獲得集約建設、資源利用最大化的同時，也意味著風險共擔。政務云建設需要評估資源間的依賴關系，適當對 IT 資源進行解耦，減少 IT 資源的關聯風險，以及對關鍵 IT 資源進行容災備份，確保構建在政務云上的系統安全持續運行。

不將所有雞蛋放在一個籃子，是各地政務云建設應當遵循的一個標準。當前，政務云建設分為內外網，以及兩地三中心或異地容災的建設模式。即通常情況下，在同一個政務云的數據中心，管理者會將政務內網系統和外網系統劃分為兩個區域，它們之間的 IT 資源相互獨立，同時同城采用主備模式，在同城 50 公里左右的地方構建備用政務云數據中心，當生產數據中心的系統發生故障，要么在本地數據中心進行系統切換，要么整體切換到備用數據中心，實現系統應用的容災保護。最后，為了避免區域性災害如地震、火災、洪災、戰爭可能造成的毀滅性破壞，對于重要系統和數據庫數據，還需要在異地建立災備中心，用于關鍵系統和數據的恢復，符合等保要求。

圖 6.1-1 電子政務架構圖 在這種“一朵云二張網三中心”的運營管理模式下，電子政務在業務方面，劃分為兩類：一類是以省-市州-區縣-鄉鎮為四級行政機構的電子政務模式，專注于政府便民服務、政策發布執行和公文傳輸等；一類是以省廳-市州局-區縣分局-鄉鎮營業所（行業稱呼略有差別）的模式，專注細分業務的對外服務、政策執行發布和公文傳輸等（如公檢法）。

不同的領域和單位，有不同的數據安全和業務連續性需求，等級保護和分級保護要求也不一樣，綜合分析，主要存在以下需求：

業務數據本地備份、CDP

本地數據庫讀寫分離和容災本地應用系統的容災高可用關鍵系統的異地跨平臺容災

政務云虛擬機遷移和云災備內外網兩地三中心容災備份 綜上，隨著電子政務的落地發展，構建政務云之間的災備體系將是下一步的建設重點，防范網絡入侵和病毒攻擊將是首要任務，同時系統故障帶來的對外服務窗口的關閉，如政務掛號系統故障、發布防洪資訊的網站訪問不了，都會帶來一定的社會影響。為此，需要制定完備的容災機制，確保數據不丟、業務不停。

6.1.3 應用場景與解決方案 實現電子政務的數據安全和業務連續性建設，需要捋清楚電子政務的系統網絡建設情況，特別是政務內外網、多種異構平臺情況、二層與三層網絡應用等。

目前，我國電子政務網絡系統分為政務內網和政務外網，內網是為政務系統自建的私有網絡，外網一般指互聯網，政務內外網通過信息安全交換系統，實現信息的交換，兩者是相互隔離又相互補充的關系。

政務內網：以滿足政府內部辦公的需求為主，通過獨立的軟硬件設備達到物理隔離的目標，對上與國家電子政務內網互聯。政務內網為了安全覆蓋范圍盡可能少，主要用于傳送電子公文，以及不適合通過外網傳輸的信息，比如政務信息、視頻會議等信息。

政務外網：以政府公共服務網為主，組織機構及民眾可以通過政府公共服務網查詢相關的政務信息。政務外網與互聯網通過網絡安全系統邏輯連接，是政務機構人員與外面進行信息交流的通道，是政務公開和為民辦事的主要窗口，各單位通過網站對外提供網上服務、受理申請等，典型代表為各類政府信息門戶網站。

互聯網出口：在異地災備建設過程中，互聯網出口是系統故障完成切換后，政務系統繼續對外提供服務的網絡端口。通常情況下，按照規定政府機構的下屬單位上網，應該統一上聯到政府信息中心的互聯網出口，但業務的不同，會存在個別政府單位因為工作需要或其他原因，可以搭建獨立的互聯網出口。

異構平臺系統：政務數據中心有一個顯著的特征，是供應商錯綜復雜，品牌繁多，不同的數據中心，存在虛擬化平臺異構、服務器異構、存儲系統與硬件異構、數據庫異構等問題；此外，結構化與非結構化數據也對政務大數據平臺、數據湖、容災備份等應用帶來挑戰。

網絡層容災切換：政務系統內外網的通信，以及在兩地三中心或異地容災的情況下，會涉及不同網絡層的應用。在故障發生時，英方軟件通常采用的故障切換接管方法，分為在二層網絡環境下，會采用 VIP 漂移技術，實現故障的切換；在三層網絡環境下，可以采用負載均衡方式，實現故障切換；在廣域網環境下，支持與 DNS 服務器無縫結合，實現故障切換。

綜上，針對不同場景不同網絡環境下的政務系統，電子政務主管部門根據各個系統安全等級保護的要求，需要做出相應的調整，當本地數據中心發生故障或出現重大災難時，可以馬上進行容災切換及數據恢復。而對于數據安全和業務連續性的建設，采用同城或異地的主備數據中心、兩地三中心等方案，不僅可以實現省級（直轄市）的政府及組織電子政務云平臺的容災備份，還可以實現地市級（區縣）政務系統的容災備份。

英方軟件在電子政務領域擁有豐富容災備份的項目實踐經驗，可以為用戶提供政務系統的跨平臺遷移、本地容災備份、異地數據庫數據實時同步和系統容災、云容災、兩地三中心災備等解決方案。由于政務機關分門別類較多，難以逐一陳述，下面我們挑選幾個有代表性的場景進行介紹。

圖 6.1-2 政府及組織電子政務云整體架構

（1）海量虛擬機跨平臺遷移和容災 場景特點：虛擬機數量大；虛擬化平臺及版本異構。

用戶需求：本地或云端到云端的系統熱遷移；虛擬機的備份和故障快速切換接管。

圖 6.1-3 跨虛擬化平臺系統熱遷移 應用實踐：在本地或異地數據中心，通過 i 2 M o ve

系統在線熱遷移軟件，在不影響日常政務服務的前提下，可以將系統從 V M w a r e

虛擬化平臺遷移到 K V M

+

O p e n S t a c k的異構平臺上，同時增量數據及 IP 地址可一起遷移到新的平臺上，整個遷移進程自動化，遷移成功率高。與此同時，由于平臺型故障對虛擬機集群可以造成致命打擊，為此需要通過 i 2 A v a il a b ili t y

實現重要虛擬機系統的容災，保障業務連續性。

（2）政務云兩地三中心災備 場景特點：虛擬機規模大、內外網環境；等級保護和分級保護要求不同。

用戶需求：建設兩地三中心災備，保留互聯網出口；重要系統同城容災，數據異地備份；數據庫數據的實時同步和讀寫分離。

圖 6.1-4 政務云兩地三中心災備 應用實踐：兩地三中心的模式下，災備建設遵守內外網相互隔離的原則，并根據用戶需求決定是否在災備端保留互聯網出口；在本地生產中心到同城災備中心異構虛擬化平臺的過程中，通過 i 2 A c t i ve

數據庫語義級的數據實時復制和同步軟件，實現數據庫讀寫分離和容災；同時通過 i2Availability 實現異構平臺核心業務容災接管；最后通過 i2CDP、i2FFO 進行本地到同城，同城到異地的數據同步和備份，可以有效防范邏輯錯誤、勒索病毒的攻擊，保障數據和業務的安全。

（3）公安廳警務系統異地容災與數據庫雙活 場景特點：等級保護和分級保護要求不同；各個平臺的異構問題突出。

用戶需求：數據庫數據的實時同步和讀寫分離；建立同城或異地容災中心；實現跨平臺的容災接管。

A

A

A

A

A

A

A

A

A

A

A

A

A

A

A

A

A

A

A

A

A

A

A

A

圖 6.1-5 公安廳警務系統異地容災與數據庫雙活

應用實踐：在專網環境下的本地和異地數據中心，通過 i 2 A c t i ve

數據庫語義級的數據實時復制和同步軟件，將 O r a c l e

R A C

實時同步本地災備服務器，然后在實時同步到異地災備中心；然后通過 i 2 A v a il a b ili t y

高可用軟件實現對本地業務系統的異地容災，確保業務應用系統發生故障時，可以秒級進行切換接管。

（4）

公檢法海量 NAS 文件異地災備與數據庫雙活 場景特點：機密性強、等保要求高；海量小文件，平臺異構。

用戶需求：NAS 下海量小文件的災備；本地或同城的系統容災。

圖 6.1-6 公檢法海量 NAS 文件異地災備與數據庫雙活

應用實踐：在專網環境下的本地和異地數據中心，通過 i2NAS 海量文件同步軟件，將 NAS 存儲下的服務器變化的數據，匯集到本地 i2NAS 服務器，然后定時或實時將變化的數據同步到容災中心；通過 i 2 A v a il a b ili t y

實現對本地業務系統的容災高可用，確保關鍵系統發生故障時，異地容災中心可快速接管應用；通過 i2Active 數據庫語義級的數據實時復制和同步軟件，將 Oracle RAC 實時同步到本地或異地容災中心。

（5）

大數據管理局數據庫容災及

CDP

保護場景特點：數據集中管理，非結構化數據多 用戶需求：數據庫系統的容災和數據備份；異構數據庫在大數據平臺的數據流通；數據庫數據CDP 保護。

應用實踐：在本地大數據中心，通過 i2Active 將 Oracle RAC 同步到備端 Oracle 數據庫單機服務器，然后通過 i2CDP 實現數據庫數據的持續保護；針對 Oracle、MySQL、SQL Sever 等數據庫到大數據平臺的應用需求，可通過 i 2 S t r e a m

數據流復制管理軟件，采用抽取、轉換、裝載的方式，實現異構數據庫平臺之間數據的傳輸及數據到 Kudu、Hadoop 等大數據平臺，打破數據孤島，i2NAS i2NAS 的

實現數據互聯互通。

6.1.4 典型用戶案例 圖 6.1-7 大數據管理局數據庫容災及 CDP 保護（1）某公安廳跨平臺異地容災 項目亮點：在硬件及虛擬化異構的情況下，實現重要數據庫數據異地約 400 公里的跨平臺實時同步和容災，以及重要警務系統的高可用異地容災和災備服務器數據的實時同步備份。

項目需求：結合公安信息化發展現狀和實際需求，新疆公安廳計劃按照國家標準化管理委員會頒布的相關等級保護要求，建立一個集中、統一、高效的異地災備系統，以提高公安廳重要信息系統和數據的安全等級，實現異地容災和數據庫的雙活。

圖 6.1-8 某公安廳跨平臺異地容災架構圖

Oracle

XML SQL CSV TXT JSON

Oracle RAC

i2CDP

i2COOPY

解決方案：

1.

在本地環境下，通過 i2Active 實現 Oracle RAC 到 Oracle 災備數據庫的實時同步，然后再通過 i2Active 實時同步到異地災備中心； 2.本地虛擬化平臺搭建各類警務系統，通過 i 2 A v a il a b ili t y

高可用軟件對本地業務系統的異地容災，確保應用系統發生故障時，可以秒級進行切換接管； 3.在本地的數據中心，通過 i 2 C D P

實現各類警務系統的重要數據，持續備份到本地的災備服務器，然后通過 i2COOPY 實時同步到異地災備中心。

（2）遵義市住房公積金中心異地容災與互為災備 項目亮點：確保了公積金中心核心業務系統、綜服管理系統、結算系統的應用容災，以及海量非結構化數據庫的數據同步備份、CDP 和文件保護，構建了遵義市公積金中心到鹽城市公積金中心的異地容災模式，首創兩市公積金中心“互為災備”的新模式，在確保重要數據異地備份、系統容災的同時，突破傳統異地容災成本高、可用性低、數據備份窗口大等難題，是“互聯網 + 政務服務” 的創新實踐。

項目需求：實現公積金中心核心業務系統、綜服管理系統、結算系統的異地容災，確保數據和業務的安全；同時通過互為災備的模式，減少異地災備中心的投入。

解決方案：

圖 6.1-9 遵義市住房公積金中心容災架構圖 1.在生產中心通過虛擬化技術，將服務器資源分配給相應業務系統，然后通過 i 2 A v a il a b ili t y字節級數據復制高可用軟件，應用程序與災備中心應用服務器進行一對一的應用高可用容災；數據庫與災備中心數據庫服務器 i 2 B o x-C

進行一對一的應用高可用容災；當生產中心某臺虛擬機出現故障時，災備中心相應的服務器可秒級接管，繼續對外提供服務。

2.

通過虛擬化技術將災備數據庫服務器 i 2 B o x-C

針對生產中心 A I X

小型機系統下的核心業務數據庫進行集群，通過 i 2 A c t i ve

數據庫語義級同步軟件，將集群實時同步到災備數據庫服務器 i 2 B o x-C

上，實現核心數據庫集群從 A I X

小型機到 X 86

服務器的高可用容災；最后業務系統通過 i2A v ail ability

高可用軟件，在災備數據庫服務器 i2Bo x-C

上實現一對一高可用容災。

i2Box-C i2CDP

3.

針對生產中心 A I X

小型機上的應用程序和憑證數據，通過 i 2 B a c k u p

備份到災備 A I X

小型機應用服務器上，確保重要應用和數據的備份保護。

4.

通過內嵌的 i 2 C D P

災備一體機 i 2 B o x D-A，對存儲了生產端重要數據庫的災備中心數據庫服務器 i 2 B o x-C

進行持續數據保護，當數據庫數據出現損壞、丟失、中病毒等情況時，可以通過 CDP 數據恢復到任意時間點的數據。

6.1.5 小結 電子政務系統是政務和群眾之間溝通的重要渠道，是提高政務辦公效率的重要工具，也是信息化社會發展的基礎。建設人民滿意的數字化服務型政府，離不開電子政務平臺提供的技術支撐，而保障電子政務應用系統和數據的安全，離不開數據復制核心技術和容災備份等產品方案。在政務云數據中心領域，適合云和大數據應用場景的數據復制技術，將幫助用戶解決各類應用場景的災備需求，滿足不同平臺、不同網絡層和不同等級保護的需求。

7.1 災備市場概況 第七章 災備市場與行業趨勢 2020 年受新冠疫情的影響，以餐飲、旅游和娛樂為代表的行業，受到了嚴重的沖擊。上半年，全世界主要經濟體的 GDP 更是遭到重創。但是我們也可以看到，機構數字化轉型的速度并沒有受到太大的影響，反而在應對疫情造成的社交困境時，線上業務展示了非常強大的靈活性和韌性，這也極大地促進了文件同步、數據流動和業務連續性在安全合規方面的發展。

2020 年國際安全形勢也是推動市場發展的原因之一，包括以國家安全為借口對業務合規性的審查，蓄意挑起地區沖突，利用網絡技術滲透攻擊機構的重要系統和數據，以及對關鍵技術和制造業資源的爭奪，都促使相關機構加大對數據和業務安全的保護——將重要數據和系統進行多重保護，以備機系統構被攻擊時，可以有最新的數據進行業務的恢復。譬如，以半導體芯片為例，一些機構就加大了生產系統和業務數據的異地備份的保護力度。

從中國第三方災備技術服務商的市場營收分析，市場強勁的需求一直存在，但是第一季度因疫情采取的社交限制，確實給一線的銷售帶來挑戰。不過隨著疫情被控制，第二季度以后，銷售的拜訪及營銷活動走出 V 字型的反彈。

這表明中國災備市場也具備強勁的發展韌性，而推動市場需求發展的兩大因素：一個是中國經濟的高速發展，市場主體充滿活力，特別是今年提出的“新基建”戰略，極大地提振了科技企業、資本和市場研究機構的信心，繼續推動企業的數字化轉型；一個是中國長期堅持的將信息安全納入國家安全戰略，并出臺了“網絡安全法”、“等保 2.0”、“數據安全（草案）”等一系列的法律，以國家實行網絡安全等級保護制度明文規定所有運營主體，需要對所轄的信息系統嚴格按照要求進行保護。

7.1.1 市場高速增長 各類研究機構對中國災備市場的增長預估都非常樂觀。智研咨詢的報告顯示：中國災備行業市場規模從 2010 年的 49.8 億元，增長至 2018 年近180 億元的市場規模，預計至 2022 年中國災備 行業市場規模可達 300 億元以上。

前瞻產業研究院的報告重點提到云災備將成未來主流趨勢，其中云災備市場規模從 2013 年的億元快速增長到 2018 年的 10 億元，預計到 2022 年我國云災備市場規模可達 70 億元。

信息技術研究和分析機構 Gartner 預計，到 2020 年存儲安全（尤其是云存儲安全）支出將繼續攀升。如今復雜的地緣政治環境將法規遵從性推到了企業的首要任務，2019 年整體安全支出增長10.5%，預計未來 5 年云安全將增長 41.2%。同時，Gartner 也預計到 2021 年，使用備份而非歸檔方式來管理企業長期數據的比例將從 2017 的 30% 上升到 50%。

根據白皮書內容編委的調查，在中國經濟高速發展的三十多年中，特別是從 2010 年互聯網開始進入高速發展階段，中國災備產品和市場也得到大力發展，中國災備市場頭部企業的融資金額也一輪比一輪高。災備產品從傳統的存儲數據備份發展到物理機、虛擬機系統的備份和容災，數據庫同步和容災也逐漸發展壯大，并成為災備市場重要的應用場景之一。根據公開的資料整理，2010 年

我國災備行業市場規模約 49.8 億元，2015 年達到 136.8 億元，近幾年中國災備市場規模大體情況

49.8 55.1 60.3 73.9 88.7

如下：

400

300

200

106.5 127.8 151.8

177.4 207.8

240.5

280.3

329.1

0 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022

圖 7-1 2010-2022 年中國災備行業市場規模 國際災備市場也同樣發展強勁，根據 DataCore 發布的 2018 年度 SDS 白皮書《The State of Software-Defined Storage，Hyperconverged and Cloud Storage》內容，有 20% 的用戶計劃將存儲預算的 25% 用在第二存儲（災備）上。

G a r t n e r

公開的數據分析報告提到：

2016

年市場規模已達 20

億美金，預計 2021

年的市場規模將達到 37.3 億美元。

M ar ketsandM ar k ets的相關數據也顯示，全球備份和恢復市場總額將從 2017

年的 71.3

億美元上升到 2022 年的 115.9 億美元。相比備份與恢復市場，云災備即服務（DRaaS）全球市場呈現出快速增長的態勢。

Gartner 的調研報告顯示，預計 2021 年的 DRaaS 市場規模將達到 37.3 億美元；到 2022 年全球云安全市場規模將達到近120 億美元；Gartner DRaaS 魔力象限中的 10 個國外玩家市值總和

超過 1000 億美金。

7.1.2 市場多元發展 災備脫胎于傳統的存儲廠商——為了解決存儲冗余的問題，用戶在尋找災備方案時，首先想到了存儲廠商，為此很多傳統存儲廠商，同時也是傳統災備方案的提供商。但是，隨著整個信息技術產品的不斷迭代，災備應用場景也從同機房的本地備份容災，向同城、異地及云端等更宏大的場景延伸，用戶數量更大，產品也更加豐富。

從傳統的備份產品開始，災備產品正在不斷拓展邊界，目前主要涵蓋了傳統的系統備份、容災和恢復；數據同步、分發、脫敏、副本管理；大數據管理和應用；數據庫讀寫分離和容災；文件管理、共享和保護等。

災備技術也從傳統的存儲復制技術，延伸到基于主機操作系統、數據庫、文件和網絡等五大數

據復制技術。在中國，基于上述五種數據復制技術的災備企業，每家企業的產品側重點不同，其中

于災 有專注于傳統的備份廠商，有專注于虛擬機容災的廠商，有專注于文件共享備份的廠商，有專注于數據復制副本管理的廠商，也有專注于數據庫容災的廠商。英方軟件是國內集多種復制技術于一體，核心技術自主研發的基礎軟件廠商，能夠提供全域、多層次、多策略、多副本數據管理的全棧解決方案。

7.2 未來五年（2021-2025）趨勢 7.2.1 信創推動核心技術自主研發 信創在網上公開的定義是信息技術應用創新產業，信創涉及的行業包括IT 基礎設置：CPU 芯片、服務器、存儲、交換機、路由器、各種云和相關服務內容；基礎軟件：數據庫、操作系統、中間件； 應用軟件：OA、ERP、辦公軟件、政務應用、流版簽軟件；信息安全：邊界安全產品（如網絡）、終端安全產品（如災備）等。

圖 7-2 信創概念圖 信創是一項國家戰略，是當今形勢下國家經濟發展的新動能，發展信創是為了解決“卡脖子” 的安全問題，即通過自主創新把核心技術變成我們自主可控、可發展、可生產的技術。信創產業發展可以助力關鍵企業突破卡脖子技術，提升關鍵產業鏈的發展，促進社會經濟的數字化轉型，保障國家戰略安全。

信創產業從技術體系構建，強化產業基礎研究，加強資金政策保障能力等方面著手，促進信創產業在關鍵領域和重點地區的落地生根，并帶動傳統信息技術產業的轉型，構建自主可控的信息技術應用產業集群。

災備技術是為確保信息系統和數據安全的關鍵技術，以核心的數據復制技術為基礎，廣泛應用備、數據保護、云數據管理等領域，幫助各類用戶打破數據孤島，實現數據互聯互通，助力數 字經濟的發展。信創產業的發展，將極大推動字節級復制、數據庫語義級復制、變長塊等核心技術的自主研發，實現數據復制卡脖子技術的不斷突破和創新應用，為國防、金融、政務、醫療、電信、能源、交通等行業保駕護航。

英方作為基礎軟件企業，在信創產業方面，擁有“卡脖子”技術，并在創始團隊的帶領下，不斷發揮自身在基礎軟件、技術創新、國產化生態體系等方面的優勢，與各個生態伙伴一起形成發展

合力，積極參與各地各行業的信創產業發展。

從創始之初，英方就積極布局國產化數據復制技術，并聚焦核心數據復制技術的研發和推廣。截至目前，英方已掌握十多項先進的核心發明專利，從字節級數據復制技術，到數據庫語義級復制技術，再到變長塊級數據復制技術，并以核心數據復制技術為基礎，先后推出 i 2 A v a il a b ili t y

應用高可用、i2Active 數據庫容災、i2Stream 大數據同步、i2Distributor 數據分發、i2CDP 持續數據保護、i2CDM 數據副本管理等重磅產品，并在政務、國防、公檢法等行業獲得廣大用戶的高度認可。

同時，英方始終與國產軟硬件廠商保持互通，實現多方產品兼容適配，并持續跟進其版本迭代和新產品的兼容情況，全面擴展英方災備軟件的適配性，構建完善的災備和數據復制生態體系。截至目前，英方災備軟件已完成國內主流云廠商（浪潮云、曙光云、華為鯤鵬云等）、芯片（如兆芯、龍芯中科、飛騰、華為鯤鵬等）、操作系統（中標麒麟、普華、紅旗、華為 F u s i o n S p h e r e

等）、數據庫（山東瀚高、人大金倉、達夢、南大通用等）等重要國產化企業產品的兼容適配，拓展國產化生態戰略合作。

此外，英方在近幾年先后通過了國家信息安全產品認證、涉密信息系統產品檢測認證、信息安全管理體系認證、公安部計算機信息系統安全專用產品認證等，并成為全國信息安全標準化技術委員會成員、國際災難恢復協會（DRI）指定服務商、災備技術國家工程實驗室合作單位、災備技術產業聯盟會員單位、國家高新技術認證企業等。

在地方信創產業布局以及各行業國產化進程中，英方作為災備國產化廠商，在政務云、大數據局、公檢法等領域的國產化產品替代方面發揮了重要的作用。如：成都政務云通過英方 i 2 M o ve在線熱遷移解決方案，在不影響全市政務服務的基礎下，實現 2000

多臺虛機從 V M w a r e

平臺到 KVM+OpenStack平臺上的遷移；南京棲霞區大數據管理局基于英方 i2CDP 和 i2Active 的災備解 決方案，在實現數據庫間實時備份和連續數據保護的基礎上，大大降低了帶寬壓力、系統災后恢復時間、后期運維工作等；海南省交通警察總隊通過 i2Active 實現全省各地分發庫的聯動，實現生產 庫讀寫壓力的分流，有效提升生產庫的性能。

作為災備及數據管理領域的頭部企業，英方不僅不斷加大數據復制核心技術的研發投入，確保災備及數據管理領域的卡脖子技術自主可控，還積極參與高精尖信息化技術人才的培養，以及各地、各行業和各生態伙伴的信創產業活動，在技術標準、人才培養、體系建設方面貢獻力量。

7.2.2 合規性仍是推動行業發展主因 信息系統和數據安全的合規性，是指系統的運營主體或責任人要制定安全保障機制，通過網絡安全、容災備份、物理安全等技術方案，實時保障系統和數據的安全，并符合國家等級保護要求和分級保護要求。

頻發的安全事件時刻挑動信息系統運維人員的敏感神經，從網上公開的資料顯示：

2020 年 2 月 23 日，微盟公司員工惡意破壞公司線上生產環境及數據，導致系統服務不可用，給商家經營造成了嚴重的影響，并帶來了廣泛的社會輿論。根據各方預測，此次微盟數據庫刪除的直接損失大約在 40 億元左右。在刪庫事件以后微盟集團在港股連續大跌，三天內市值跌逾 30 億港元。這是典型的內部權限管理帶來的安全問題，是建立內部合規性管理機制要重點關注的范疇。

2020 年 8 月，由于 IT 失誤，全球會計巨頭畢馬威的 1.45 萬個微軟 Teams 用戶的聊天記錄被

永久性刪除，且微軟確認這些聊天數據不可恢復。這是典型的弱 IT 行業在應對數據安全方面的反面教材，值得所有國家的公司提高警惕，并相應改善數據安全的保護措施。

2020 年 8 月，Maze 黑客團伙聲稱，通過 Maze 勒索軟件攻入韓國半導體巨頭 SK 海力士。Maze 黑客團伙官網的屏幕截圖顯示，有 5% 的 SK 海力士數據被泄露，并以此作為黑客成功入侵 SK 海力士的證據。這是典型的針對知名機構發起的勒索病毒攻擊的違法行為，并且與傳統的勒索軟件加密文件系統相比，Maze 為勒索軟件找到更能攻擊受害者軟肋的方法，那就是先公開泄露竊 取的少數信息，如不繳納贖金，黑客們可能會公開所有的包括敏感信息在內的數據。

綜上三個公開的案例信息，針對信息系統和數據安全的合規性保護，仍將是信息技術行業不可回避的話題。中國在近年加大了包括系統等級保護、數據安全和個人隱私等領域的立法工作，并在政務、金融、醫療等行業取得顯著效果。譬如，政務云的兩地三中心建設過程中，信息系統應用級容災及數據多重備份，為信息化政務的業務連續性管理提供安全可靠的支撐，確保當潛在的威脅事件發生時，業務恢復的 RTO 和數據恢復的 RPO 能夠達到最小，將經濟性損失和非經濟性損失降到最低。

7.2.3 平臺化推進災備產業化發展 維持一個產業的可持續發展，需要構建以政策、法律、資本、人才和技術產品等為核心的產業體系。作為合規性方面的重要終端安全產品的技術方案，災備保護的系統和數據越來越復雜，大型組織機構針對災備產品的運維開始力不從心：運維人員要解決不同產品、不同系統、不同技術服務商在災備方面的運維難題，包括產品的操作習慣和不兼容、沒有統一的管理平臺、備份系統可用性驗證人力化等。

如何解決上述問題，災備平臺化以及依托平臺進行智能化運維是一個可靠的方案。我們針對金融、醫療、政務和大型企業的深入調研分析發現，實現災備平臺化智能運維，可能會集中在以下三個方面：

一是云災備平臺化。云災備包括了云平臺本身提供的基礎版的云備份和云容災方案，通過分布式架構劃分高可用區，為租戶提供基于自身基礎架構的云災備服務。從傳統的災備架構分析，雖然可以通過不同云數據中心劃分高可用區向外出租，但是作為非主營業務，災備產品投入的產出比，還是處于艱難維持的階段，更多是處于自身高可用方案的完整性和安全性做出的投入，發展動力是不足的，并且相比于第三方技術方案商，同等投入情況下，云平臺在數據級災備的 RPO 值更大。

另外一種更具靈活性的云災備平臺方案，是云平臺聯合第三方技術方案商，云平臺可以彈性地提供各種云資源，技術方案商提供云災備平臺，包括涵蓋數據同步和系統遷移工具，跨平臺的容災產品，定時或實時備份和 CDP 保護，用于災備演練的獨立網絡等產品方案。此外，云災備平臺也向更靈活的災備即服務方向發展，例如英方軟件與運營商結合打造的 i 2 C l o u d

云平臺，可以根據用戶的需求，不僅可以為每個租戶分配管理賬號，個性化保護指定的業務系統和數據，還可以通過設 置網絡帶寬大小和災備時間靈活地使用災備產品，做到與云計算一樣的按需使用和付費。

二是 CDM 超融合數據管理平臺。災備是數據復制技術典型的應用場景之一，高效的數據復制能力帶來更廣闊的綜合應用場景。為此，復制數據管理（C o p y

D a t a

M a n a g e m e n t，C D M）是近年快速發展起來的產品，作為備受 G a r t n e r

推崇的數據管理產品，C D M

將傳統的數據復制進行融合，將分散的數據集中起來，通過自動化策略，對復制數據進行集中管理，不僅可以助力企業加速

雙模式 IT 運作的落地，同時可以改進數據保護的性能，縮短應用開發的周期，對業務產生直接價值。簡單地講，CDM 為用戶解決了數據災備的同時，也可以為用戶提供用于測試、演練所需的真實的 業務數據，直接提高了備份數據的附加值。

經過近幾年的快速發展，CDM 產品逐漸成熟，并形成基于 CDM 的超融合數據管理平臺。以 i 2 C D M

超融合數據管理平臺為例，該平臺將數據管理的生命周期劃分為四個部分：生產環境異構——從服務器到操作系統到數據庫到虛擬化平臺的異構；容災環境——從字節級復制到數據庫語義級復制到塊變化實時復制技術，整合現有的數據復制技術，實現初始全量數據 + 持續增量數據的復制；超融合數據管理平臺——提供單一黃金副本，然后虛克隆出多個任意數量、任意歷史時間、可讀可寫的虛擬副本，節省存儲資源；應用場景——應急恢復、數據遷移、開發測試、數據恢復、培訓環境等。

三是統一數據管理平臺。災備解決的是系統和數據的安全問題，但是隨著數據量的不斷增加和數據價值進一步被挖掘，用戶希望基于數據復制技術的災備產品可以提供更多的功能，比如跨平臺跨區域的結構化和非結構化數據實時同步，跨異構數據庫的數據同步和跨大數據平臺的數據流動管理，打破數據孤島，實現數據的互聯互通，并最終為商業智能提供可快速利用的數據報表。

以證券行業為例，一個大型的證券機構，其各種業務和管理 IT 系統多大兩三百個，這些系統每天新增的各種結構化和非結構化的數據多達幾個 TB，且呈現加速之勢。這些數據包括客戶的賬戶數據、交易數據、產品與服務數據、市場相關的數據、風控數據，以及機構本身的管理數據和 IT 運維數據等，通過統一數據管理平臺（如英方軟件 i 2 U P），可以為證券機構提供全域多層次多策略的統一數據管理，滿足用戶各類數據實時同步、CDP（持續數據保護）、各類數據庫實時同步、各類虛擬機保護、兩地三中心，異地容災、多副本快速交付、多應用數據全面統一管理等需求。

7.2.4 災備人才和用戶群體持續增長 經過十幾年的發展，災備技術從傳統的存儲分支（第二存儲）獨立發展至今，逐漸形成了一大批專業的技術和營銷人才。從技術人才構成看，分為傳統型人才和新型技術人才。傳統人才主要以傳統的存儲容災、數據庫容災、IT 運維等技術人員為主，他們擁有資深的行業背景，對用戶的 IT 運維場景非常了解，能夠針對用戶的災備需求，快速提供不同層次、不同策略的災備解決方案，在傳統的本地災備向云災備過渡過程中，發揮了關鍵的作用。

新型人才以應屆畢業生為主，同時隨著災備行業的快速發展，也吸引了一批其他泛 IT 行業的人才的加入。他們普遍年輕化，擁有較高的文化水平，學習和接受新事物的能力更強，以及擁有更多可以獲得專業知識的網絡渠道。他們的加入，給整個行業帶來了活力和創造力。他們欠缺的是行業經驗和知識，為此，技術服務商提供的專業工程師認證培訓服務，是提升這批新型人才專業技能非常好的平臺。例如像英方軟件舉辦的工程師認證培訓和 DRI 在中國舉辦的 CBCP、MBCP 認證等，都為中國災備行業培養了大量的專業技術和管理人才。

伴隨專業人才隊伍的擴大，用戶群體也越來越龐大，他們之間以正相關的關系，螺旋式推動災備產業向上發展。目前，在政務、金融、醫療、教育、電信、能源、制造、交通等行業，凡是涉及信息系統和數據安全合規的領域，都離不開等級保護和分級保護的建設需求。為此，災備用戶是一個相當大的群體，但是由于長期由于人力成本的問題，大部分機構并沒有專職的災備管理人員，更多是通過運維人員兼職的形式，實現災備項目的管理。但是從近幾年的信息系統安全事件可以發現，專業性不夠是造成很多災備用戶在發生安全事故時，仍然造成數據丟失和業務停止的主要原因。未雨綢繆，防微杜漸，隨著數字化轉型的加速，所有機構都應該從人員思想和習慣上培養員工的安全防范意識，做好相應的管理權限分級工作，逐步完善企業災備人才隊伍和機制體系的建設。對于重要的行業機構，更應該將災備工作提升到二把手工程或一把手工程，并最終實現災備與數據管理應用合二為一的目標。

第二篇：災備建設的四大誤區

災備建設的四大誤區

來源：中國計算機報

2010年08月24日11:44 我來說兩句(0)復制鏈接 打印

大中小

作者：郭濤

企業只要投巨資建設了災備系統，以后就不會再出現業務中斷和數據丟失了嗎?其實，災難備份/恢復與業務連續性有很大的差別，不能將兩者混為一談。“對災備的錯誤認知是導致災備建設失敗的重要原因。”EMC公司資深業務連續性咨詢顧問許瑀表示。

容災不等于業務連續性

一些企業領導的固有思維是：容災與業務連續性是一回事，只要擁有了災備系統，就不應該再出現業務的停頓。其實，災難備份主要用于應對較大的災難事件，而不是針對局部的事故。業務連續性的概念更寬泛，無論是局部的故障，還是重大的災難，都不能使業務中斷。

許瑀表示：“災難備份是業務連續性的基礎，是企業多層次信息保護體系的重要組成部分。為確保業務連續性，企業應優先考慮建設基本的災難備份和恢復系統。在?9·11?災難事件中，美國世貿中心里數百家沒有災難備份系統的公司徹底消失了。這充分體現了災難備份作為企業信息架構基礎組成部分的重要性。在建立了完善的災備系統后，企業可以考慮構建多層次的信息保護體系，進一步提升業務連續性水平。”

由于投入的資金數量不同，信息基礎設施的狀況不同，災備建設的思路不同，不同行業的用戶在建設災備系統時，很難遵循一個統一的策略。不過，企業在建設災備系統時應遵循這樣一個原則，即無論采用何種技術手段，都必須保證數據的安全。這是災備建設的底線。

重異地災備 輕本地保護

“實際上，導致信息系統出現中斷，97%的原因是物理設備故障和系統的邏輯錯誤，只有3%的業務中斷是由大災難引起的。”許瑀分析說，“本地數據保護與異地災難恢復都非常重要。有的用戶認為，只要建設了異地災難恢復系統就能抵御所有的災難，因此忽視了本地的數據保護。這其實是一個誤區。”

許瑀舉例說：“某用戶的磁盤出現故障，由于換盤時的錯誤操作導致了核心數據庫的損壞。該用戶利用本地備份系統恢復數據，恢復時間長達一周，而且丟失了兩天的數據。”有用戶盲目追求過高的異地災難恢復RTO和RPO指標，要求RTO小于4小時，RPO小于15分鐘。但事實上，該用戶在進行本地數據恢復時，RTO大于1天，RPO為24小時。用戶投巨資建設災備系統，卻不能減少因本地故障帶來的損失，這其實是本末倒置。許瑀認為，只有將信息系統的本地數據保護和異地災難恢復相結合，才能構成完善的業務容災體系。本地數據保護與異地災難恢復防范的風險不同，因此采用的技術手段、機制和措施也不一樣。有些需要面向公眾提供服務的系統，對災難恢復的時間要求十分嚴格。但是大多數信息系統對災難恢復等級的要求并不太高，通常可以接受幾小時的災難恢復時間。對于大多數用戶來說，最重要的不是恢復時間的長短，而是數據能夠100%被恢復。

RTO、RPO指標過高

在建設災備系統的過程中，RTO和RPO是兩個非常重要的指標。那么，RTO與RPO的數值是不是越小越好呢?“某銀行針對其網上支付業務建設災備系統時，提出系統恢復時間小于30分鐘(即RTO小于30分鐘)，只能丟失5分鐘的數據(即RPO小于5分鐘)。”許瑀表示，“我看到用戶的RTO和RPO指標要求時，第一感覺就是這不現實。因為銀行的系統出現故障后，為了恢復數據，技術人員通常要根據日志對活動賬號進行分析，而所有的日志分散在多個業務系統中，處理這些日志可能要采用手工方式。完成上述一系列步驟，銀行至少要花費一兩個小時的時間。”

企業在制定災備恢復的目標時，一定要從業務的實際需求出發，不能盲目追求過高的RTO、RPO指標。過高的RTO和RPO指標不僅會增加災備建設的成本，而且會讓用戶迷失在數字游戲中，對業務的保護無益。

忽視日常的運維管理

“2007年，某公司的核心業務系統發生意外宕機，多個關鍵業務數據庫癱瘓。公司領導決定啟用同城災備系統。但是在進行恢復時，技術人員發現，容災端數據嚴重滯后于生產端數據，災備系統根本無法啟用。”許瑀舉例說，“事后，人們在追查原因時發現，由于系統管理員在進行災備端測試時中斷了災備數據的復制關系，測試完成后又忘記了恢復災備數據的復制關系，從而導致災備系統無法啟用。”

在某些企業中，災備系統完全成了擺設。平時，這些企業的技術人員不對災備系統進行定期檢查，而且忽視了災備演練。因此當災難發生時，災備系統很難發揮作用。中金數據系統有限公司高級副總裁陳天晴告訴記者，他們曾經按照合同要求為某客戶提供災備演練服務，但是客戶的相關人員總以工作忙為由推脫，造成服務合同遲遲不能履行。許瑀表示：“企業在建成災備系統后，應該定期進行災備演練，并建立完善的業務連續性計劃(BCP)，包括詳細的災難恢復計劃及本地恢復計劃等。

(責任編輯：王亞紅)

第三篇：政府行業備份容災解決方案

政府行業備份容災解決方案

隨著政府信息化建設進入高速發展白熱化階段，信息系統數據中心資源的整合和虛擬化正在不斷發展，各級政府信息化建設的步伐也明顯加快，政府電子政務建設已從服務上網向內部系統建設轉型，這就要求政府必須建設一套安全易用的備份用在系統。信息系統備份容災解決方案要求專業，高效，安全，簡單易用。中科同向為政府信息系統建設建立的備份容災解決方案屬于綠色型：高可用，節省成本，安全易操作，為政府協同辦公，建立友好信息環境。

政府行業信息系統表現出以下特點：

1、數據復雜。政府網與電子政務網不但是高級政府單位建設，基層也建設了完善的電子政府系統，而且全國統一搭建平臺，互通，實現了全國聯網統一。各部門單位數據中心統一存放，數據多樣性復雜性可想而知。

2、數據中心管理人員業務繁多。作為信息系統管理人員，需要了解各方面的信息業務，包括操作知識，操作技能，各方面業務需要精通。否則遇到信息災害時會無力回天，造成不可估量的后果。這就要求到軟件的簡單易用，管理人員易學易會，維護簡單。

3、新舊系統連接。我國電子政務起步較晚，作為之前的大量數據需要留檔。所以要求數據備份如何接洽之前的數據到存儲保護恢復系統是一大技術難題。以前的數據格式可能多種多樣，要求備份容災軟件需要接納不同數據格式。

4、政府行業的特殊性。一些保密單位要求有保密級別，涉及到國家安全。數據的保護性要求更高，而且要求做到數據可以接管，做到應用級容災。中科同向的政府行業數據備份容災解決方案。

數據備份軟件Heartsone Backup V8.0可以安裝在windows、Linux、Unix等不同操作系統上，實現了跨平臺安裝備份。傳輸及備份壓縮后精密算法(AES3DES)這就對數據的安全更增加了一層保護，需要主管人員用密鑰打開壓縮數據包。對恢復數據點擊選擇要恢復的數據，點擊確定即可。

高度的數據備份安全需要做數據持續保護CDP。CDP技術中科同向實現了PTO=0，RPO=0，做到了零數據丟失，保證業務的連續性，在故障期間瞬間恢復數據。中科同向CDP數據保護采用了四步驟，被稱為“四金剛”。

企業應用級容災DR，對數據庫日志進行抓取，分析，保持了同步數據備份容災。對數據庫、文件、系統可以做到實時增量備份，可以設置不同的備份策略，實現了局域網和異地容災。

在未來的政府信息發展中，數據已經作為政府的關鍵性依據，中科同向將不斷在技術上創新，和政府齊心協力，做好政府信息化建設，在數據備份容災方面永創第一！

第四篇：工商銀行上海數據中心災備系統運維實踐

工商銀行上海數據中心災備系統運維實踐

一、“兩地三中心”建設歷程

工商銀行于1999 年開啟了數據中心集約化建設的先河，在北京、上海分別建設兩大數據中心后，于2002年1 月在國內同業率先啟動了主機災難備份工程。經過多年的建設和持續投入，已經實現了高等級的核心系統災備體系建設，完成了全行應用分等級災備體系建設。為進一步提升信息系統災難恢復能力，工商銀行啟動了 “兩地三中心”工程建設。根據規劃，2014 年將在上海嘉定建立同城數據中心，與上海外高橋數據中心構成同城雙中心，同城雙中心整體與北京異地災備中心組成異地災備模式(如圖1 所示)。

“兩地三中心”模式可以滿足不同災難場景下的恢復要求，實現更靈活的風險應對。在架構布局上，上海同城雙中心具備基本相同的業務處理能力并通過高速鏈路進行實時數據同步，兩個中心之間距離約55 千米，日常情況下可按主/ 備或雙活模式運行。在發生區域級災難某個中心失效時，可在基本不丟失數據的情況下進行雙中心間的應急切換，保持業務連續運行。北京異地災備中心用于同城雙中心的災難恢復，當出現因大范圍自然災害等原因導致同城雙中心同時失效時，異地災備中心可以用災備系統接管全行核心業務。

二、“兩地三中心”技術手段和實施策略

工商銀行通過技術攻關，完成了“兩地三中心”模式下的信息系統業務連續性架構設計和方案研究，提出了可以提供多層級業務連續性保障水平的解決方案。信息系統可以給銀行業務應用提供A/A、A/Q 和A/S 等多種部署模式，最終以業務影響分析結果作為應用部署模式選型的決策依據。

在具體實施中，工商銀行堅持“全面覆蓋基本保障能力、重點針對關鍵核心應用部署高等級災備保障技術”原則，做好資源分等級和差異化配置。如ATM、POS、柜面業務、資本市場等核心業務系統是銀行的關鍵應用，與其相關的應用系統就具有較高的業務連續性等級。自2010 年工程啟動以來，項目進展情況良好，完成方案規劃設計和驗證評審，在數據庫復制技術全面推廣、智能網管改造、55 千米磁盤同步鏡像等關鍵技術領域取得了突破;完成了核心主機并行系統投產，即雙園區模擬同城雙活的試運行，目前主機并行系統主要運行可分離查詢交易，分流了部分核心生產系統的負載壓力;完成13 個開放平臺應用服務器雙活改造，預計今年將完成近50 個開放平臺應用的雙活改造。同時，工商銀行積極探索“兩地三中心”運行模式，按照“一體化管理”原則，初步制定了“兩地三中心”生產運行管理方案，并對組織架構和主要職能進行了規劃。嘉定同城數據中心園區基建工程按計劃推進，于2011 年底奠基，2012年4 月開工，2012 年底8 萬平方米基建工程結構封頂，計劃今年底機房樓交付使用，2014 年嘉定同城數據中心園區建成啟用，實現“兩地三中心”的數據中心布局。

三、“兩地三中心”安全措施

1.建立全面、系統、可持續發展的信息安全管理體系

①以安全、穩定、高效、追求卓越為安全方針建立具有工商銀行特色的ISO27001 信息安全管理體系。數據中心(上海)于2011 年通過了ISO27001:2005 信息安全管理體系認證，實現在信息安全組織、資產管理、人員安全、物理和環境安全、通信及操作管理、訪問控制等11個方面130 余個控制點的全方位的信息安全管理體系。同時，建立起具有工商銀行特色的支撐跨地域統一管理的ISO27001信息安全管理體系，主要包括信息安全制度管理、安全生產與運維管理、安全與防控技術管理、用戶與人員管理、綜合管理等五大方面共107 項精細化管理制度。

②建設信息安全組織體系確保信息安全管理有效開展。數據中心成立了信息安全領導小組，作為信息安全管理最高管理機構，確定信息安全方針、目標和控制策略，明確信息安全的管理職責。信息安全領導小組定期或不定期召開聯席會議，分析信息安全形勢，研究中心信息安全管理薄弱環節及應對措施，貫徹落實監管部門、上級機構信息安全管理要求等。中心建立了縱、橫向聯系報告機制，及時掌握并報告本區域重大信息安全事件、案件線索或案件，提示風險，有效防控風險。

③信息安全管理體系隨著工商銀行和中心自身的發展、內外部安全形勢的不斷變化，與時俱進持續改進。主要措施包括：定期對人員、硬件、軟件、數據與文檔等各類重要資產所面臨的風險進行評估，結合現有技術能力和管理成本，制定相關的補償控制措施;利用有效的技術平臺，通過完整、系統、及時的問題整改跟蹤管理，將內外部審計檢查發現的問題進行分析匯總，在督促及時完成整改的同時，不斷挖掘制度漏洞和流程缺陷，及時完善管理體系;主動對生產故障事件、外部信息安全重大事件等進行分析研究，深入剖析問題發生和防控失效的深層次原因，進一步細化制度執行要求、強化技術硬控制、優化生產運維流程;積極與外部審計監管單位、各行業先進企業進行溝通，主動學習借鑒國際先進標準和業界領先經驗，不斷完善優化中心的信息安全管理體系。

2.生產運維安全措施多管齊下，確保生產穩定運行

①努力降低變更引發的安全生產問題。變更前通過變更評審會和變更協調會對高風險度變更和跨多個部門的變更進行評估和協調;變更中嚴格按照雙人復核提交方式進行變更操作;變更后及時開展技術和業務驗證。根據應用等級和對外服務時間嚴格控制變更窗口，嚴格控制緊急變更。將環境搭建和版本升級準備等相關變更活動限制在與生產環境隔離的區域，進一步降低變更操作風險。

②持續完善應急管理。制定完備的應急和災備演練計劃，開展層次豐富的各類演練，及時總結演練過程發現的問題并加以改進，定期開展南北兩地互相遠程接管演練等。

③ 建立了涵蓋主機、網絡、平臺、UPS、應用、安全等各領域的集中監控報警平臺，統一了監控報警事件的處理流程，使得各類報警能得以快速處理。

④ 定期對生產事件進行總結分析，找到問題根源和解決方案，避免事件的再次發生和深層次安全隱患。建立完善的事件溝通機制，通過每日、每周及不定期專項會議將相關事件發生原因、處理過程、改進措施等進行分析總結，舉一反三防微杜漸。

⑤高度重視性能容量管理，建立了覆蓋操作系統、數據庫、中間件、網絡、存儲、動力、應用等領域的較為全面的性能容量指標和監控系統及指標閾值和報警規則，并結合實際生產情況、版本變化定期進行全面的指標梳理。定期開展性能容量統計分析，根據分析結果進行相應擴容、改造或資源回收。

⑥進一步完善運行操作管理，提高批量操作自動化水平，減少人為干預。通過專業系統對操作步驟制定、修改、發布、執行過程記錄等進行信息化、流程化、自動化管理。實現了管理嚴謹、操作有序的安全生產目標。

⑦以“知其所需、最小授權、唯一鑒別、有效控制”為原則，進行各類用戶權限的劃分和按需發放，通過細致的訪問控制，降低操作類安全事件發生的可能性。

⑧進行嚴格的網絡區域劃分，實現生產與外部網、生產與辦公網的隔離。在接入網和互聯網區域網絡邊界部署入侵檢測防護設備，實現對攻擊事件、DOS/DDOS 事件的檢測和防護。

⑨ 通過技術手段嚴格落實數據訪問、數據變形、數據傳輸、數據恢復、數據清理、數據銷毀等數據管理各環節的安全管理要求。同時建立完善的客戶端安全技術防護體系，包括防病毒管理、系統補丁管理、軟硬件管理、外發郵件管理、互聯網訪問管理、電子文件安全管理、信息泄漏防護管理、筆記本硬盤密碼保護管理等，實現客戶端的安全準入控制和數據安全管理。

⑩通過日志集中和安全審計平臺建設，對各類生產系統的人員操作、系統安全事件等進行快速和全面審計，及時發現和通報違規操作、惡意攻擊、高風險操作等現象。

四、未來發展規劃

未來，工商銀行數據中心要努力實現生產運行管理可控、可靠、可持續的目標。可控，即對日常運維和突發問題可以主動安排和快速把控;可靠，即能提供穩定可靠運作的基礎設施環境，確保全行信息系統運行不因物理設備故障而中斷。可持續，即在任何時候、任何情況下均不發生對外服務中斷。為此重點要做好以下幾方面工作。

一是樹立“安全生產第一”和“第一時間恢復生產”的指導思想，落實各項生產運行管理措施。包括提升監控的覆蓋率、準確率和時效性;提升應急管理效率，確保在應急情況下，能夠立即切換，第一時間恢復生產;提升生產一線發生事件的處置能力;提升變更管理和應用版本投產管理質量;提升健康檢查、性能容量分析水平，提前采取預防和改進措施，切實降低重大生產事件發生概率;提升對境外機構的生產運行管理和服務，強化中心針對分行管理的專業人員的配備，完善對分行生產系統的遠程實時監控能力，抓好分行機房動力設施、網絡通信線路的改造升級等。

二是進一步提升信息系統的高可用性和災備能力。要積極推進以數據零丟失和“本地雙活、異地災備”為原則的“兩地三中心”建設，高標準、高質量建設上海同城中心;要積極推動應用系統災備體系優化，根據應用災備等級劃分的要求，加快推進開放平臺應用系統的災備建設，確保關鍵開放平臺應用系統均具備異地災備能力。

三是加強生產運維的自動化工具研發與投入，不斷提升操作、監控、維護、資源配置的自動化程度。推動實現數據中心批量操作自動化比例達到98% 以上;要全面建立覆蓋各應用系統的“端到端”業務級監控，推動數據中心運行維護和資源配置的自動化，從而全面提升數據中心例行化工作的質量和效率。

四是以風險管理為核心，建立覆蓋全流程的信息安全管理體系，不斷提升信息安全管理水平。通過風險評估的方法，建立、實施、運行、監視、評審、保持和改進信息安全工作的流程與規范。

五是建立科學合理的人力資源配置和激勵機制，加快建設數據中心專業化人才隊伍。要合理配置人力資源，加強行業領軍人才和高級專業人才培養，建立人才梯隊，穩定人才隊伍。

第五篇：IBM容災白皮書

IBM的容災白皮書 內容簡介

隨著時代的發展，人類對于災難的防范意識和要求越來越高。災難的概念范疇非常廣泛，本書針對于企業環境，對業界當前討論的熱門話題--IT容災系統的概念和實現方法及設計流程做了深入淺出的分析，并從多個層面介紹了相應的解決方案。希望讀者通過本書可以加深對于容災系統的理解，對設計出一個切實可行的容災系統能夠有所幫助。

第一章 信息—企業的財富與麻煩

前言

1.1 IT大集中 － 把蛋都裝進籃子里

1.2 容災－覆巢之下，亦有完卵

第二章 容災概述

2.1 概述

2.2 容災的實質是確保永不停頓的業務運營

2.3 容災的IT實現

第三章容災方案分析

3.1 業務連續性開發模式

3.2 七層災難恢復解決方案

3.3 如何選擇最優的災難恢復方案

第四章 容災系統的設計過程

4.1 災難恢復計劃描述

4.2 災難恢復計劃項目階段

4.3 數據收集和關鍵需求分析階段

4.4 風險分析階段

4.5 數據保護階段

4.6 恢復階段

4.7 測試和培訓階段

4.8 維護和修改階段

4.9 選擇災難恢復方案的步驟介紹

第五章 典型方案介紹

5.1 基于軟件的數據備份技術

5.2 HACMP高可靠性災備方案

5.3 基于磁盤系統的PPRC數據級災難備份解決方案

附錄A.容災方案演示環境

6.1 基于磁盤系統的PPRC數據級災難備份解決方案典型應用環境

附錄B.術語

第一章 企業面臨的挑戰以及發展趨勢

1.1前言

1958年，Bill Gore 和他的太太 Vieve Gore在美國特拉華州Newark市，自己家里的地下室成立了Gore公司。1969年，Gore公司研制成功獨特的，具有防風、防水、透氣功能的GORE-TEX面料并廣泛應用于生產具有功能性、保護性和時尚感的服裝和鞋類產品。目前，Gore公司已成為一家在全球擁有6000多名員工、40多間加工廠的跨國公司，并在氟材料的技術研究和應用領域始終占據世界領先地位。

對于Gore這樣的以研發新型材料作為企業動力的公司而言，材料的研發過程記錄、研發歷史數據、研發結果數據是企業最可寶貴的財富。請假設這樣一種情況，如果這些數據在一次事故中全部丟失，Gore公司會蒙受多么大的損失？

1983年，當個人電腦還處于萌芽期的時候，美國青年戴爾成立了自己的個人電腦公司，主要銷售IBM的舊電腦和自己組裝的品牌電腦。那是一個電腦群雄激烈廝殺的年代，當行業的領導者們爭相以引人注目的技術推出計算機時，戴爾注意到了平凡的供應鏈。戴爾公司利用信息技術全面管理公司生產過程。通過互聯網，戴爾公司和其上游的配件制造商能夠對客戶的定單迅速地做出反應：當定單傳至戴爾的控制中心時，控制中心把定單分解為一個個子任務，并通過網絡分派給各獨立配件制造商進行生產。各制造商按照戴爾的電子定單進行生產組裝，并按照戴爾控制中心的時間表來供貨。戴爾所需要做的只是在成品車間完成組裝和系統測試，剩下的就是客戶服務中心的事情了。―經過優化后，戴爾供應鏈每20秒鐘匯集一次定單‖，―平均庫存時間僅有7小時‖。雖然沒有傲視群雄的杰出技術，現在的戴爾公司卻已成長為一個年銷售額達410億美金的企業。

對戴爾公司來說，市場信息的獲取、物流信息的傳遞以及合作伙伴的信息交換，這些共同構成了拉動企業正常運轉的信息鏈。如果有一天，一場意外的事故導致供應鏈的崩裂，戴爾該如何面對客戶惱怒的面容和企業直線下滑的利潤？

信息，作為企業寶貴的資源，其重要性已經得到了人們的充分認識。但是我們該如何保護這一資源？假設您就是某企業的一位高級管理人員，當您的企業遭遇以下事故時，您將如何去面對： 1． 某一天，證券公司的交易數據因操作失誤而損壞； 2． 某一天，保險公司的所有保單數據因電源故障而丟失；

3． 石油勘探公司辛苦一年獲取的地質數據因人為的惡意操作而丟失； 4． 醫院保存的所有病歷因為磁帶的損壞而無法使用； ……

這樣的例子還有很多很多。那么這樣的事故所帶來的后果是什么？至少，很難想象這個不幸的企業還能毫發無損的健康生存。因為，對于信息時代的企業而言，健全的信息往往是維持其運轉所必須的基本條件。所以，如何保護企業的信息資源，如何使企業免遭信息災難，已經成為企業所必須考慮的沉重問題。

1.2 IT大集中 － 把蛋都裝進籃子里

在計算機應用的早期，是大型主機一統天下的時代。這是一種高度集中的信息應用模式。昂貴的計算機和同樣昂貴的存儲設備躲藏在幽深的機房里，客戶僅能依靠啞終端與主機進行交互，以完成自己的工作。

隨著IT設備的降價和網絡技術的發展，客戶機/服務器體系結構和瀏覽器/服務器體系結構這樣的信息應用模式應運而生。這兩種全新的信息應用模式，降低了用戶進入計算機應用系統的門檻，推進了計算機應用在現代社會的全面普及，并產生了今天計算機應用分布式存在和數據存儲分布式存在的局面。

合久必分，分久必合。隨著網絡速度的進一步提高以及高速存儲設備的降價，高速信息交換、大容量存儲等困擾IT人員多年的問題基本得到了解決。同時，過于分布的應用和數據所導致的日益昂貴的維護和運營費用，已經給大型企業的發展帶來了束縛。于是，大集中的號角重新吹響。

目前，在銀行信息化領域，數據大集中已經成了一個熱門的話題。在國內，中國工商銀行在2000年就前瞻性地啟動了數據大集中工程，并在2002年完成了全部工程的建設。現在，中國工商銀行已經將分布在全國各地的四十多個數據中心整合為互相連接、互為備份的北京、上海兩大數據中心，建成了全行統一的計算機系統平臺。同時，國內的其它銀行和大型證券公司也紛紛迎頭趕上。大集中已經成為包括銀行、證券、保險等行業在內的整個金融信息化發展的大趨勢。

鑒于信息資源對于企業的寶貴作用，我們不妨把它們比作一枚枚金蛋，而信息基礎設施就是用來裝這些金蛋的籃子。過去，不同的金蛋分布在不同地域的籃子里，而大集中所帶來的信息基礎設施整合則意味著我們將把越來越多的金蛋放進同一個籃子。此刻，一個不得不考慮的問題出現了：如果這個籃子翻了，怎么辦？覆巢之下，豈有完卵？

1.3 容災－覆巢之下，亦有完卵

2001年9月11日，美國世貿中心雙子大廈遭受了誰也無法預料的恐怖打擊。災難發生前，約有350家企業在世貿大廈中工作。事故發生一年后，重返世貿大廈的企業變成了150家，有200家企業由于重要信息系統的破壞，關鍵數據的丟失而永遠的關閉、消失了。其中的一家公司稱，自己要恢復到災難前的狀態需要50年的時間。

2003年，當AT＆T無線試圖對Siebel客戶關系管理（CRM）軟件進行升級的時候，原定一個周末就能完成的項目演變為一場歷時六個星期的災難。這次CRM軟件的升級使AT＆T無線損失了1億多美元，僅增加的用戶欠款、員工加班費和承包商的傭金就高達7500萬美元。此外，技術故障也導致該公司去年第四季度的新增用戶數急降82％。而其損失并不僅限于這些，AT＆T無線對分析師發布警告稱：―2004年上半年的用戶退網率將進一步增加。‖ 2003年，國內某電信運營商的計費存儲系統僅發生了兩個小時的故障，就造成400多萬元的損失。這些尚不包括對公司聲譽的影響所導致的無形資產流失。

這些災難的發生或許是偶然而難以預料的，但是，對災難的預防卻絕對不應該是一個偶然的話題。

據IDC的統計數字表明，美國在2000年以前的10年間發生過災難的公司中，有55%當時倒閉。剩下的45%中，因為數據丟失，有29%也在兩年之內倒閉，生存下來的僅占16%。國際調查機構Gartner Group的數據表明，在由于經歷大型災難而導致系統停運的公司中，有2/5再也沒有恢復運營，剩下的公司中也有1/3在兩年內破產。

美國德克薩斯州大學的調查顯示：―只有6%的公司可以在數據丟失后生存下來，43%的公司會徹底關門，51%的公司會在兩年之內消失。‖

另一份針對這一課題的研究報告也顯示：在災難之后，如果無法在14天內恢復信息作業，有75%的公司業務會完全停頓，43%的公司再也無法重新開業，20%的企業在兩年之內被迫宣告破產。

美國明尼蘇達大學的研究也表明，在遭遇災難的同時又沒有災難恢復計劃的企業中，將有超過60%在兩到三年后退出市場。而隨著企業對數據處理依賴程度的遞增，此比例還有上升的趨勢。

災難的發生對企業的打擊往往是致命的。但是，面對災難，企業就真的不堪一擊嗎？

答案是否定的！

同樣是令人恐怖的―9.11‖，世貿大廈倒塌后，在世貿大廈租有25層的金融界巨頭摩根斯坦利公司最為世人所關注。但是事發幾個小時后，該公司宣布：全球營業部可以在第二天照常工作。這都是因為該公司建立的數據備份和遠程容災系統，它們保護了公司的重要數據，在關鍵時刻挽救了摩根斯坦利，同時也在一定程度上挽救了全球的金融行業。

這一獨特的例子說明了什么？它說明擁有先知先覺的防范意識和充分的技術準備，即使是在突如其來的覆巢之災下，亦有完卵，亦有企業的一線生機。

因此，預防災難的發生，充分考慮災難發生后的快速恢復手段，成為現代企業的一門必修課。其實，在這一問題上，中國古代的智者早就提出了自己的觀點：生于憂患，死于安樂。無論是對一個國家，還是一個企業，都是如此。第二章 容災概述

2.1 概述

常言道，―知己知彼，百戰不殆‖。要實現容災，首先要了解我們的―敵人‖－ 災難。那么，哪些事件可以定義為災難呢？典型的災難事件是自然災難，如火災、洪水、地震、颶風、龍卷風、臺風等，還有其它如原先提供給業務運營所需的服務中斷，如設備故障、軟件錯誤、電信網絡中斷和電力故障等等。此外，人為的因素往往也會釀成大禍，如操作員錯誤、破壞、植入有害代碼和恐怖襲擊。現階段，由于我國很多行業正處在高速發展的階段，很多生產流程和制度仍不完善，加之缺乏經驗，這方面的損失屢見不鮮。事實上，我國2003年遭遇的―非典‖，某種意義上也是災難。對此，我們認為需要做到兩點：一是建立切實可行的應急機制，這主要包含一套基于充分且清楚地將風險予以分類定義的業務持續計劃，二是在危機突然降臨時，此計劃能被有效執行。

對于IT系統，除了上述的災難之外，與系統相關的計劃外宕機也可視作災難（見圖1）。

圖1.停機原因分析－北美

自―9.11‖之后，全球各企業均認識到災難防范保護的重要性。某些大型金融機構之所以能夠在兩天內恢復營業，其主要原因是它們不僅象一般公司那樣在內部進行數據備份，而且在數英里外的數據備份中心也保留著數據備份。這些備份都是通過數據備份軟件和數據復制軟件進行的。采取了這種措施后，一旦工作現場發生意外，企業就可以立即使用另一套數據。華爾街的金融機構重新對災難恢復的步驟做了評估，并認識到災難恢復只是技術手段之一，它們開始強調 Business Continuity“災難”恢復。因為過去的“災難”恢復計劃并沒有強調全局性及對整個市場的影響，而如何維持業務的連續運作將成為企業運營風險評估中至關重要的一環。事實證明，只有對數據存儲備份制定完備、持續且可執行的容災計劃，特別是業務連續計劃，才能為人們提供萬無一失的數據安全保護。

嚴格的說，容災計劃包括一系列應急計劃，如業務持續計劃(BCP-Business Continuity Plan)，業務恢復計劃(ERP-Business Recovery Plan)，運行連續性計劃(COOP-Continuity of Operations Plan)，事件響應計劃(IRP-Incident Response Plan)，場所緊急計劃(OEP-Occupant Emergency Plan)，危機通信計劃(CCP-Crisis Communication Plan)，災難恢復計劃(DRP-Disaster Recovery Plan)等等。

業務持續計劃(BCP)它是一套用來降低組織的重要營運功能遭受未料的中斷風險的作業程序，它可能是人工的或系統自動的。業務持續計劃是高層管理人員的首要職責，因為他們被委任于保護公司的資產及公司的生存。業務持續計劃的目的是使得一個組織及其信息系統在災難事件發生時仍可以繼續運作。為了能對災難事件有適當的對策，嚴密的計劃及相關資源的投入是必須的。

業務恢復計劃(BRP)它也叫業務繼續計劃，涉及緊急事件后對業務處理的恢復，但與BCP不同，它在整個緊急事件或中斷過程中缺乏確保關鍵處理的連續性的規程。BRP的制定應該與災難恢復計劃及BCP進行協調。BRP應該附加在BCP之后。

操作連續性計劃(COOP)COOP 關注位于機構（通常是總部單位）備用站點的關鍵功能以及這些功能在恢復到正常操作狀態之前最多30天的運行。由于COOP涉及到總部級的問題，它和BCP是互相獨立制定和執行的。COOP的標準要素包括職權條款、連續性的順序和關鍵記錄和數據庫。由于COOP強調機構在備用站點恢復運行中的能力，所以該計劃通常不包括IT運行方面的內容。另外，它不涉及無需重新配置到備用站點的小型危害。但是COOP可以將BCP、BRP和災難恢復計劃作為附錄。

危機通信計劃(CCP)機構應該在災難之前做好其內部和外部通信規程的準備工作。危機通信計劃通常由負責公共聯絡的機構制定。危機通信計劃規程應該和所有其它計劃協調，以確保只有受到批準的內容公之于眾，它應該作為附錄包含在BCP中。通信計劃通常指定特定的人員作為在災難反應中回答公眾問題的唯一發言人。它還可以包括向個人和公眾散發狀態報告的規程，例如記者招待會的模板。

計劃(IRP)事件響應計劃建立了處理針對機構的IT系統攻擊的規程。這些規程用來協助安全人員對有害的計算機事件進行識別、消減并進行恢復，這些事件的例子包括：對系統或數據的非法訪問、拒絕服務攻擊、或對硬件、軟件、數據的非法更改（如有害邏輯：病毒、蠕蟲或木馬等）。本計劃可以包含在BCP的附錄中。

災難恢復計劃(DRP)正如其名字所表示的，DRP應用于重大的、通常是災難性的、造成長時間無法對正常設施進行訪問的事件。通常，DRP指用于緊急事件后在備用站點恢復目標系統、應用或計算機設施運行的IT計劃。DRP的范圍可能與IT應急計劃重疊，但是DRP的范圍比較狹窄，它不涉及無需重新配置的小型危害。根據機構的需要，可能會有多個DRP附加在BCP之后。

場所緊急計劃(OEP)OEP在可能對人員的安全健康、環境或財產構成威脅的事件發生時，為設施中的人員提供反應規程。OEP在設施級別進行制定，與特定的地理位置和建筑結構有關。設施OEP可以附加在BCP之后，但是獨立執行。

BCP關注在中斷期間和之后維持機構的業務功能。業務功能的一個可能的例子是工資的支付處理或客戶的信息處理。BCP可以專門為某個特定的業務處理編寫也可以涉及到所有關鍵的業務處理。IT系統在BCP中被認為是對于業務處理的支持。在某些情況下，BCP可能沒有涉及到對過程的長期恢復并使其回到正常運行狀態，而只是包含過渡的業務連續性需求。災難恢復計劃、業務繼續計劃和場所緊急計劃可以附加在BCP之后。在BCP中設定的職責和優先順序應該和其在操作連續性計劃（COOP）中的一致以消除可能的沖突。

按一般慣例，備用站點維持機構（通常是總部）要支持長達30天的運行，直到整個系統恢復到正常狀態，COOP正是為了達到這個要求而制定的。BCP涉及到在重大中斷期間和之后維持業務處理所需的業務功能和IT系統。BRP記錄了機構在備用站點進行業務處理的持續規程。與BCP不同，BRP不涉及在緊急事件期間對關鍵處理的連續性維持。DRP是指設計用于重大和通常是毀滅性災難之后的目標系統、應用程序或計算機設施的恢復，它是以IT為主的計劃。兩個計劃都提供了IT系統的恢復和繼續規程。由于包括了對無需重新部署到備用站點的小型中斷進行系統恢復的規程，所以這類計劃比DRP的范圍更廣泛。計算機事件響應計劃建立了使安全人員可以確定、防止和恢復針對機構IT系統進行的計算機攻擊的規程。OEP則提供了在人員的健康和安全以及環境或財產等受到威脅的緊急情況下，設施工作人員所遵循的指導方針。計劃的制定者之間必須進行協調以確保各自的策略和規程能夠互為補充，必須將所有有關計劃、系統和處理的變化情況反饋給系統和相應處理計劃的制定者。2.2 容災的實質是確保永不停頓的業務運營

讓我們來看一個真實的故事：

Fred Alger基金管理公司的總部設在世貿中心北樓的93層。在上個世紀90年代，Fred Alger曾是美國業績最好的一家基金管理公司。它旗下的―光譜共同基金‖（Spectra mutual fund）的年均收益率曾達到讓人驚羨的29%。然而，公司2000年的業績大幅下滑，其前景不容樂觀。2001年9月11日上午發生恐怖襲擊后，該公司正在上班的35人全部遇難，老板David Alger也在其中，這對Fred Alger公司來說無疑是滅頂之災。

所幸的是，該公司居安思危，在繁榮期建設的IT系統早早就考慮到容災的需要，在50英里以外的新澤西中心區建有一個數據備份點。―9?11‖過后的第三天，該公司幸存無幾的人在那里發現，襲擊之前所有的交易記錄和所有的研究報告都有詳細備份，并被完好無損地保留了下來。

所以，Fred Alger公司沒有選擇關張，而是決定重建。他們并非盲目地不認輸。幾年前就已退休的Fred Alger，在弟弟David去世后立刻再度出山。當整個市場在去年9月17日重新開市時，Fred Alger公司成了華爾街經紀公司中的股票大買家。

此后，當其他基金管理公司的業績在去年出現滑坡時，他們的利潤反而因此大大增加。很快，Fred Alger公司的投資管理隊伍也空前興旺起來，并在第五大道的2層樓建立了新的總部。類似的故事令全世界在一夜之間認識到，金融市場的數據備份和交易備份絕對不能缺少。

自美國建國以來，華爾街就一直主宰著美國的金融。而此次襲擊已經給了華爾街以致命的一擊。事實上，對世貿中心的襲擊完全改變了紐約的金融景觀。以往，曼哈頓4/5寫字樓的底層都是金融服務機構。而如今，這些金融機構中的一半以上都遷走了，大多都換了個小地方。在曼哈頓中心區的5萬名金融服務人員中，已有19000名離開了這個城市。其中也有像摩根斯坦利和高盛公司這樣的―金融巨人‖。

因此，即使在曼哈頓區還在燃燒時，監管者們已經開始考慮，如何才能重振金融業，并讓它強大到足以抵御下一次災難。在銀行家和監管者們看來，―9?11‖并不能被稱為信用事件。但下一次災難，不論是什么樣的災難，它一定會是一場信用事件。在龐大的支付鏈條上，一旦某個具有實力的環節受到支付困難的威脅，整個市場，如外匯交易或美國財政債券交易就有可能出現大塞車。

為此，英國的金融服務管理局在一個儲存有備份數據的秘密地點，進行了多次―業務持續‖演習。美國的監管者也拋出一份建議書。這份建議書的目的在于，要保持市場參與者之間實時的信息和通信聯系，即保持數據備份點之間的通信聯系。監管者和市場應該能夠抵御住沉重的打擊，并應在4小時以內恢復工作。而對那些由15～20家大銀行和5～10家證券公司所組成的金融主干系統來說，在它們主要參與的市場中應享受優先權，須在一天之內恢復營業。

在―9311‖以前，銀行之間（包括獨立的通信和信息技術系統之間）的應急計劃很少有彼此的溝通。為此，設在巴塞爾的發達國家10國 ―金融穩定性論壇‖，已經起草了一個―應急協議名單‖。被列入這一名單的，都是些全球最重要的金融實體。根據這個協議，名單中的金融實體的監管方可以在任何情況下及時取得聯系。

此外，美國監管機構已經提出，要持續不斷地進行應急計劃測試，以對付―一切可以想象得出的事件‖。例如，進行產業范圍的戰爭預演已經提到議事日程，而―無線戰爭‖被最先納入其中。

那么，如何確保企業業務的連續運營以及數據的安全呢？嚴格的說，業務持續計劃的建立和實施過程，實際上是進行一個涉及企業運營的項目，因此也涉及到項目管理的方方面面。標準的業務持續計劃項目應按如下流程進行： 1。項目啟動和管理

確定業務持續計劃（BCP）實施過程的相關需求，包括獲得管理支持、以及組織和管理項目使其符合時間和預算的限制要求。2。風險評估和控制

確定可能造成機構及其設施中斷的災難、具有負面影響的事件和周邊環境因素，以及事件可能造成的損失、防止或減少潛在損失影響的控制措施，提供成本效益分析以調整控制措施方面的投資，達到消減風險的目的。同時，由于風險會隨著系統的發展而變化，所以風險管理過程也必須是動態的。

3。業務影響分析

確定由于中斷和預期災難可能對機構造成的影響，以及用來定量和定性分析這種影響的技術。確定關鍵功能、恢復優先順序和相關性以便確定恢復時間。4。制定業務連續性策略

確定和指導備用業務恢復運行策略的選擇，以便在恢復時間目標范圍內恢復業務和信息技術，并維持機構的關鍵功能。5。應急響應和運作

制定和實施用于事件響應以及對事件所引起狀況進行穩定的規程，包括建立和管理緊急事件運作中心，該中心用于在緊急事件中發布命令。6。制定和實施業務連續性計劃

設計、制定和實施業務連續性計劃，以便在恢復時間目標范圍內完成恢復。7。意識培養和培訓項目

準備建立對機構人員進行意識培養和技能培訓的項目，以便業務連續性計劃能夠得到制定、實施、維護和執行。

8。維護和演練業務連續性計劃

對預先計劃和計劃間的協調性進行演練、并評估和記錄計劃演練的結果。制定維持連續性能力和BCP文檔更新狀態的方法，使其與機構的策略方向保持一致。通過與適當標準的比較來驗證BCP的效率，并使用簡明的語言報告驗證的結果。9。公共關系和危機通信

制定、協調、評價和演練在危機情況下與媒體交流的計劃；制定、協調、評價和演練與員工及其家庭、主要客戶、關鍵供應商、業主／股東以及機構管理層進行溝通和在必要情況下提供心理輔導的計劃，確保所有利益群體能夠得到所需的信息。10。與公共當局的協調

建立適用的規程和策略，用于同地方當局協調響應、連續性和恢復活動，以確保符合現行的法令和法規。

當然，實際應用中，如果受時間、成本等因素的限制，加之容災目標有限（企業不需要承擔應由政府負責的國計民生之重任），我們可以簡化并適當改變上述標準流程。事實上，隨著IT系統在企業內部應用的深入，IT系統更容易受到各種災難的傷害而導致中斷，特別是在許多情況下，關鍵資源可能屬于不可控范圍（如電力和電信）。對于倚仗IT系統的企業來說，從確保業務連續能力的角度出發，可以依據下列容災規劃步驟：

1． 災難類型分析 2． 業務沖擊分析

3． 當前業務環境及恢復能力分析 4． 容災策略制訂 5． 容災方案設計 6． 業務連續性流程設計

7． 業務連續性流程及容災方案管理和測試

每一個步驟的相關職責一般會落在―計劃協調人‖或―應急計劃制訂人‖的身上，他們通常是職能或資源部門的經理。協調人在其他相關系統或業務處理部門的職能經理和資源經理的協助下制定應急策略；應急計劃協調人通常管理應急計劃的制定和執行。

2.3容災的IT實現

除了詳盡的容災計劃，實際上還需要合理的IT系統架構來確保企業的容災計劃得以實現。對于IT系統而言，在技術層面上，容災需要考慮：

* 數據版本保護 － 建立容災的多版本保護底線（Bottom Line）* 實時數據保護 － 數據復制，近乎0的數據丟失，數據一致性

* 應用系統恢復 － 恢復時間（包括數據庫恢復）、應用版本的一致性（PTF）等 * 網絡系統恢復 － 數據訪問點變化、建立新網絡路徑、動態路由（收斂時間/穩定性）* 容災切換決策 － 及時發現災難（容災系統管理）、容災切換的損失和補救辦法 * 容災切換過程 － 變更管理

同時，無論任何時候，備份都是非常重要的，并要定期測試備份的可靠性。一種技術只能減少或防止某些類型的災難的影響。除了簡單或一成不變的應用，在沒有特別要求的情況下，盡量不要采用操作系統層面以上的數據復制技術。而沒有文檔化的流程就相當于沒有流程，沒有流程的系統能夠在要求時間內恢復完全靠運氣（通常不能）。

另外，在通常情況下，IT系統相關的災難備份方案設計都必須考慮以下五大因素，1，災難類型

需要考慮哪些災難？怎樣的災難？會使業務中斷多久？ 2，恢復速度

災難發生后需要多久來啟動及運行系統？能否承受數天或數分鐘的等待？ 3，恢復程度

需要恢復每條記錄和交易嗎？可以使用上星期或昨天的數據嗎？需要恢復一切嗎？有不相關的文件嗎？什么是合法隱含的要求？有少數的一組人輸入交易嗎？他們可以重新輸入災難期間丟失的交易嗎？這些交易十分重要而不容許丟失嗎？ 4，可用的技術

必須結合考慮所選技術在本地區的適用性、實現條件以及在實施時是否受某些現有條件的制約？ 5，方案總體成本

實現災難備份需要多少投資？不實現災難備份會損失多少錢？ 綜合以上所述，可以如圖2所示：

圖2.災難備份方案選擇標準

2.3.1容災的7個層次

據國際標準SHARE78的定義，災難恢復解決方案可根據以下主要方面所達到的程度分為七級，即從低到高有七種不同層次的災難恢復解決方案。可以根據企業數據的重要性以及您需要恢復的速度和程度，來設計選擇并實現您的災難恢復計劃（參見圖3）。這取決于下列要求： 備份/恢復的范圍 災難恢復計劃的狀態

在應用中心與備份中心之間的距離

應用中心與備份中心之間是如何相互連接的 數據是怎樣在兩個中心之間傳送的 有多少數據被丟失

怎樣保證更新的數據在備份中心被更新 備份中心可以開始備份工作的能力

現已證明，為實現有效的災難恢復，無需人工介入的自動站點故障切換功能是一個必須被納入考慮范圍的重要事項。目前通用的異地遠程恢復標準采用的是1992年Anaheim的SHARE78，M028會議的報告中所闡述的七個層次：

0層-沒有異地數據(No off-site Data)Tier0即沒有任何異地備份或應急計劃。數據僅在本地進行備份恢復，沒有數據送往異地。事實上這一層并不具備真正災難恢復的能力。

1層-PTAM卡車運送訪問方式(Pickup Truck Access Method)Tier1的災難恢復方案必須設計一個應急方案，能夠備份所需要的信息并將它存儲在異地。PTAM指將本地備份的數據用交通工具送到遠方。這種方案相對來說成本較低，但難于管理。

2層-PTAM卡車運送訪問方式+熱備份中心(PTAM + Hot Center)Tier2相當于Tier1再加上熱備份中心能力的進一步的災難恢復。熱備份中心擁有足夠的硬件和網絡設備去支持關鍵應用。相比于Tier1，明顯降低了災難恢復時間。3層-電子鏈接(Electronic Vaulting)Tier3是在Tier2的基礎上用電子鏈路取代了卡車進行數據的傳送的進一步的災難恢復。由于熱備份中心要保持持續運行，增加了成本，但提高了災難恢復速度。4層-活動狀態的備份中心(Active Secondary Center)Tier4指兩個中心同時處于活動狀態并同時互相備份，在這種情況下，工作負載可能在兩個中心之間分享。在災難發生時，關鍵應用的恢復也可降低到小時級或分鐘級。

5層– 兩個活動的數據中心，確保數據一致性的兩階段傳輸承諾（Two-Site Two-Phase Commit）

Tier5則提供了更好的數據完整性和一致性。也就是說，Tier5需要兩中心與中心的數據都被同時更新。在災難發生時，僅是傳送中的數據被丟失，恢復時間被降低到分鐘級。6層-0數據丟失(Zero Data Loss)，自動系統故障切換

Tier6可以實現0數據丟失率，被認為是災難恢復的最高級別，在本地和遠程的所有數據被更新的同時，利用了雙重在線存儲和完全的網絡切換能力，當發生災難時，能夠提供跨站點動態負載平衡和自動系統故障切換功能。

2.3.2容災的業務恢復時間段

對于IT系統的容災指標，我們可以通過下列參數表示： * 以恢復點為目標(RPO--Recovery Point Object）– – 數據的完整性(無數據丟失)– – 數據的一致性(數據正確且可用）

* 以恢復時間為目標(RTO---Recovery Time Object）* 以網絡恢復為目標(NRO---Network Recovery Object）* 以服務支持能力為目標(SDO---Serviceability Degrade Object)– – 性能

– – 地域/ 支持的客戶總數 – – 功能的限制

圖4展示了業務恢復的不同時間段。

圖4.容災的業務恢復時間段 2.3.3容災所涉及的恢復技術

DR（容災 Disaster Recovery）項目的實施中涉及到多種技術。這些技術可以分為三類：應用恢復，網絡恢復，數據恢復。應用恢復技術

常用的應用恢復技術或方法如下：

* 通過負載均衡提供永不停頓的系統運行能力(Tier-7)例如：IBMS/390的GDPS技術給用戶提供一個無中斷的操作環境,來運行那些關鍵業務的應用程序，通過自動應用恢復能力來滿足其第7級容災要求 * 通過事先寫好的腳本來實現自動的熱接管(Tier-6)例如：GDPS也可以在熱待命狀態下運行，來為S/390系統提供第6級解決方案。

HAGEO提供與GDPS熱待命相似的解決方案，并常被用來作為大型關鍵業務UNIX數據中心的DR解決方案

* 按預案手工實現站點接管(Tier 4/5)例如：有些設施的DR包括必須有人介入和決策的手動應用恢復程序。

在實際災難發生時，一些這樣的設施因為對人工操作的依賴，造成恢復過程的延誤。因此，我們認識到，容災的實施必須包括一定程度的自動化，這也是GDPS和HAGEO這樣的軟件的主旨。網絡恢復技術

常用的網絡恢復技術或方法如下： * 4-7 層交換機(Tier-7)例如：無中斷的第7級網絡恢復需要動態網絡路由重選，來保證應用能夠在不中斷最終用戶的情況下轉入備用數據中心。在SNA環境下通過APPN來完成，而在IP環境下則通過第4-7層轉換來完成。APPN是在IBM S/390 GDPS環境下，為動態網絡恢復而開發的SNA網絡技術。通過標準的基于路由器的技術，可以在通用的IP傳輸上使用APPN * 路由(Tier-6)例如：在第6級DR的實施中，網絡恢復可以通過APPN和/或標準的路由協議來完成(OSPF / EIGRP / BGP-4)在非GDPS環境中，APPN應用路由在容災系統備用路徑可用時，自動恢復網絡連接

* 2層 Reconnect(Tier-4/5)例如：SNA子網在以太網/SNA中通過ATM / 幀中繼 / DDN 鏈路進行互聯，如果發生鏈路故障，則可以通過手工切換來實現網絡恢復

數據恢復技術

數據容災系統的實現可以采用不同的技術。一種技術是采用硬件進行遠程數據復制，我們稱為硬件復制技術。這種技術的提供者是一些存儲設備廠商，其技術例如PPRC、SRDF。數據的復制完全通過專用線路實現物理存儲設備之間的交換；另一種技術是采用軟件系統實現遠程的實時數據復制，并且實現遠程的全程高可用體系（遠程監控和切換）。這種技術的代表則是一些存儲軟件廠商，其技術例如HAGEO、VVR。

數據復制是一個復雜的議題，但一般來說這，它可以在硬件或軟件層上實施（參見圖5）。今天，市場上的硬件和軟件技術提供不同的第4級和第7級數據恢復，對硬件或軟件的選擇取決于很多與設施相關的因素，如工作量、網絡成本要求、工作點和數據恢復點間的距離、同性或異性的平臺支持等等。我們將在下面的章節對以上兩種技術進行詳細的論述。

圖5.數據復制技術 第三章 容災方案分析

業務連續性開發模式 | 七層災難恢復解決方案 | 如何選擇最優的災難恢復方案

在現代企業的IT系統管理過程中，常常會遇到各種有關災難備份范疇的需求，例如：

―無論發生任何問題，業務系統必須在最短的時間內恢復！‖； ―無論發生任何問題，數據絕對不能丟失！‖ ……

針對這些問題，有經驗的管理人員可能會考慮到一系列由此引發的問題： ―究竟有些什么因素可能導致業務中斷？‖ ―究竟最短的時間是多長？‖

―是否所有的應用系統數據都不能丟失？‖ ―這些恢復目標是否合理？‖

―目前的IT架構是否能夠滿足所要求的恢復目標？‖

―是否IT系統得到恢復，就意味著業務部門可以對客戶進行服務？‖ ―如何衡量災難備份方案的投入產出比？‖ ……

回答以上這些問題的過程，就是考慮企業業務連續性的過程。事實上，隨著IT系統在企業內部應用的深入，災難備份在企業中已不是IT一個部門的問題，而是整個企業各業務部門與IT部門緊密合作的問題。其內容也不僅局限于數據的備份和應用的接管，還包含了網絡的冗余、人員與組織架構的整理、恢復流程的設計等一系列技術以外的范疇。目的在于保證在災難環境下，企業真正從業務的角度得到保護，而不僅僅是IT環境的恢復。

3.1業務連續性開發模式

各行各業的用戶，需要針對自身情況，設立可行的業務恢復目標，并制訂出切合實際、投資合理、可靠的業務連續性及技術方案。這種業務連續性開發模式，體現在業務連續性或災難備份的項目中，就是災難備份項目實施的步驟：

1.災難類型分析 2.業務沖擊分析

3.當前業務環境及恢復能力分析 4.容災策略制訂 5.容災方案設計 6.業務連續性流程設計

7.業務連續性流程及容災方案管理和測試

其過程如下圖所示，是一個周而復始的過程，隨著企業內部環境的變化隨時靈活變化：

圖一.災難備份項目實施過程

3.1.1階段

一、災難類型分析（風險分析）

在本階段，需要進行詳細而量化的風險分析，以確定當前IT環境之中存在哪些無法接受的物理威脅或者可能發生的災難，并對災難發生的可能性、目前可能的防護措施的有效性和該災難所威脅的資產價值進行分析，最終得到帶有優先級別的需要防護的災難列表，并制訂可能的處理方法，如接受該災難發生的風險而不進行防護、自行制訂該災難的防護方法或者采取購買保險等風險轉嫁策略。其結果可以由下圖表示：

在該圖中，橫坐標為風險發生的可能性，縱坐標為風險發生所造成的損失。在某一風險發生的可能性極小時，即使造成的損失極大，也可能屬于可接受的風險范疇，例如美國的―9?11‖事件。但該接受程度是與時俱進的，在―9?11‖事件發生后，事實是大部分沒有考慮這種大范圍災難性事件的企業基本沒有得到恢復的機會。目前業界也已經將低概率事件逐漸納入防護的范圍。

3.1.2階段

二、業務沖擊分析

在本階段，應該針對各種業務流程進行分析，通過走訪各業務部門的相關人員，了解各種業務流程本身對該企業的重要程度。（例如在銀行業里，儲蓄和單據、網上支付、電話銀行等業務就具有不同的優先等級。）同時根據一定的評判原則，得出在核心流程由于災難的發生而無法正常進行時對企業本身的損失情況。這種損失可能是可以量化的，例如單據的丟失、計算的錯誤而導致的直接損失；也可以是無形的損失，例如客戶滿意度及競爭優勢的丟失。通過對可量化和不可量化損失的綜合考慮，得出各種核心業務流程由于災難受損的可容忍程度及損失的決策依據。體現在IT系統上，是三個指標：

數據恢復點目標（RECOVERY POINT OBJECTIVE）：體現為該流程在災難 發生后，恢復運轉時數據丟失的可容忍程度；

恢復時間目標（RECOVERY TIME OBJECTIE）：體現為該流程在災難發生后，需要恢復的緊迫性也即多久能夠得到恢復的問題；

網絡恢復目標（NETWORK RECOVERY OBJECTIVE）：即營業網點什么時候才能通過備份網絡與數據中心重新恢復通信的指標；

對于不同的業務流程，這三個指標可能相差非常之大，各個流程本身對這三個目標的優先程度也是不一樣的，有的流程可能要求數據丟失的程度較小，但恢復時間可以較長，而另一些流程可能要求短時間內恢復，但數據的丟失程度可以放大一些。這三個指標直接影響所使用的容災策略及技術方案，并指導企業的投入成本。可以用下圖表示：

圖3.業務沖擊分析曲線

在該圖中，橫坐標為災難持續時間，縱坐標為災難損失，在某一程度以下屬于可接受的程度，即橫虛線所示。這種可接受決策應該由負責該流程的業務部門綜合考慮后做出。

3.1.3階段

三、企業容災環境分析 本階段主要針對業務沖擊分析的結果，對目前的內部環境進行評估，得出與恢復目標之間的差距。分析的對象為業務流程需要的資源，如IT環境等。通過本階段的工作，得出各業務流程所牽涉的企業資產及資源（人力資源、IT架構、技術儲備、技術使用程度、網絡環境等），并分析得出目前的業務環境對容災需求、冗余程度、可能造成的數據損失是否能夠支持等方面的報告。用下圖表示：

圖4.容災環境分析

圖中右邊紅線為目前環境所支持的容災能力，左邊紅線為經過業務沖擊分析所得到的需要達到的恢復能力，在災難恢復時間和災難造成損失兩個方面都需要得到降低。

3.1.4階段

四、容災策略制訂

在本階段，結合以上各階段的分析成果，以及企業本身在容災上的投入能力，制訂企業短期、長期范圍內的容災策略和目標，并有意識地將企業本身的人員組成和組織架構做出調整以適應策略要求。最重要的是制訂出容災實施步驟，優先解決最為重點的問題。如下圖所示：

圖5.容災策略制訂

3.1.5階段

五、容災方案設計

容災方案可供選擇的范圍很大，但所有的容災方案都必須考慮的因素包括恢復時間、實施與維護容災策略所需的投入等。容災恢復時間的需求越短，所需的實施成本就越大，實施難度也就越高。恢復時間與投入的比值可以用以下這張曲線圖加以說明：

圖6.容災方案層次

圖中的各種層次方案可以分別滿足不同的數據恢復目標和恢復時間目標，需要根據業務沖擊分析的結果，針對每一種業務流程，綜合選擇能夠滿足容災目標的方案。

3.1.6 階段

六、業務連續性流程設計

有了IT系統的恢復方案，只能夠保證在災難環境下，IT系統的恢復能夠保證業務沖擊分析的目標，但是業務的連續性并不只是IT系統的恢復，還包括辦公場地、辦公設備、緊急流程、指揮架構、人員調度等等多方面、各部門的綜合考慮。只有業務流程執行過程的每一個環節都達到容災目標的要求，才能夠認為業務沖擊分析的目標得到了滿足。一般來說，每個企業都應該設立一個由領導掛帥，各業務部門和IT部門聯合組成的一個容災指揮小組：

圖7.容災組織架構圖

由該小組指揮，IT部門和業務部門分別執行，IT恢復計劃和業務連續性計劃才能得到同步，從而達到容災設計的目標。

3.1.7階段

七、業務連續性流程及容災方案管理和測試

任何制訂的計劃，都必須經過不斷的測試和修正，才能滿足企業不斷發展的需求。同時，通過測試過程，也能夠使企業內部各部門及人員熟悉自己在業務連續性計劃中所扮演的角色，做到胸有成竹，才能夠在災難真正發生的時刻有條不紊地開展恢復的過程。

測試的過程可以分為―紙上談兵‖和實地演習兩種方式，根據企業需要及對業務影響的不同分別采用。

需要注意的是，無論平時的測試如何完善，也沒有辦法預測可能發生的災難情況。關鍵人員的損失或者關鍵文檔的丟失，都有可能對災難恢復計劃的執行造成巨大影響。因此，在災難演練過程中要注意到人員的交叉備份情況，除了每個人自己所擔負的責任外，盡量做到關鍵步驟有后備人選作為應變。

3.2七層災難恢復解決方案

在談到災難恢復方案時，經常提到災難恢復解決方案的7個層次(tier)。那么什么是7層解決方案？該如何為關鍵的業務應用選擇最優的容災方案？

3.2.1恢復的7個層次

災難保護計劃的目的是，確保關鍵業務持續運行以及減少非計劃宕機時間。所有與容災方案相關的計劃都試圖在方案本身、宕機時間和實施方案所需成本三者之間找到一個平衡點。

圖8.三者的平衡關系

災難恢復方案中的恢復時間與下列因素有關： 數據有效性的恢復 IT基礎設施的恢復 可操作流程的修復 關鍵業務的修復

圖9.災難恢復的層次劃分

3.2.2細述7個層次

災難恢復方案的7個層次提供了一個簡單方法論--如何定義當前的服務水平、風險以及期望的服務水平和環境。

0層：無異地備份數據(No off-site Data)對于使用0層災難恢復解決方案的業務，可稱其為沒有災難恢復計劃，主要表現為： 數據僅在本地進行備份恢復，沒有任何數據信息和資料被送往異地，沒有處理意外 事故的計劃。恢復時間：在此種情況下，恢復時間不可預測。事實上也不可能恢復。

例如，目前我們通常在機房內所做的數據備份，備份介質保留在機房內，用于本地的數據恢復。當災難發生時，數據備份和設備有可能一同被毀，無法進行恢復。

1層：有數據備份，無備用系統（Data Backup with No Hot Site）

使用1層災難恢復解決方案的業務，通常將需要的數據備份到磁帶上，然后將這些介質運送到其它較為安全的地方。但在那里缺乏能恢復數據的系統，若數據備份的頻率很高，則在恢復時丟失的數據就會少些。此類業務應能忍受幾天乃至幾星期的數據丟失。

例如，PTAM（Pickup Truck Access Method）是一種許多數據中心所采用的標準備份方式。在完成所需的數據備份后，用適當的運輸工具將它們送到遠離本地的地方，同時備有數據恢復的程序。災難發生后，一整套系統安裝需要在一臺未開啟的計算機上重新完成，系統和數據可以被恢復并重新與網絡相連。這種災難恢復方案相對來說成本較低(僅僅需要運輸工具的消耗以及存儲設備的消耗)。但恢復的時間長，且數據不夠新。

2層：有數據備份，有備用系統（Data Backup with Hot Site）

使用2層容災解決方案的業務會定期將數據備份到磁帶上，并將其運到安全的地點。在備份中心有備用的系統，當災難發生時，可以使用這些數據備份磁帶來恢復系統。雖然還需要數小時或幾天的時間來恢復數據以使業務可用，但不可預測的恢復時間減少了。

2層相當于在1層上增加了備份中心的災難恢復。備份中心擁有足夠的硬件和網絡設備來維持關鍵應用的安裝需求，這樣的應用是十分的關鍵的，它必須在災難發生的同時，在異地有正運行著的硬件提供支持。這種災難恢復的方式依賴于PTAM方法去將日常數據放入倉庫，當災難發生的時候，再將數據恢復到備份中心的系統上。雖然備份中心的系統增加了成本，但明顯降低了災難恢復時間，系統可在幾天內得以恢復。

3層：電子鏈接（Electronic Vaulting）

使用3層容災解決方案的業務，是在2層解決方案的基礎上，又使用了對關鍵數據的電子鏈接技術。電子鏈接將磁帶備份后更改的數據進行記錄，并傳到備用中心，使用此種方法會比使用傳統的磁帶備份更快地得到更新的數據。所以，當災難發生后，只有少量的數據需要重新恢復，恢復時間會縮短。

由于備用中心要保持持續運行，與生產中心間的通訊線路要保證暢通，增加了運營成本。但消除了對運輸工具的依賴，提高了災難恢復速度。

例如，某企業在每天下班后，將當日的流水全部記錄下來，通過網絡傳到備份中心；備份中心在備用系統上，重新將所有業務重做，保證與生產中心的一致性。這一領域的產品可以分四層：

1）存儲設備層：IBM-ESS-PPRC、IBM-DS4000-RM、EMC-SRDF、HP-EVA-StorageWorks Continuous Access、FALCONSTOR-IPSTOR、NETAPP等。

2）操作系統及系統軟件層：IBM-GEORM、VERITAS-Storage Replicator/Volume Replicator、LEGATAL-RepliStor。

3）數據庫層：IBM-DB2-HADR、IBM-INFORMIX-HDR、ORACLE-ORACLE-DATA GUARD等。

4）應用程序層：應用程序開發時考慮到數據的復制。

4層：使用快照技術拷貝數據（Point-in-time Copies）

使用4層災難恢復方案的業務，對數據的實時性和快速恢復性要求更高些。1-3層的方案中較常使用磁帶備份和傳輸，在4層方案中開始使用基于磁盤的解決方案。此時仍然會出現幾個小時的數據丟失，但同基于磁帶的解決方案相比，通過加快備份頻率，使用最近時間點的快照拷貝恢復數據會更快。系統可在一天內恢復。

4層災難恢復可有兩個中心同時處于活動狀態并管理彼此的備份數據，允許備份行動在任何一個方向發生。接收方硬件必須保證與另一方平臺在地理上分離，在這種情況下，工作負載可能在兩個中心之間分享，中心1成為中心2的備份，反之亦然。在兩個中心之間，彼此的在線關鍵數據的拷貝不停地相互傳送著。在災難發生時，需要的關鍵數據通過網絡可迅速恢復，通過網絡的切換，關鍵應用的恢復也可降低到小時級。支持這種工作方式的產品包括IBM-HAGEO、VARITAS-Global Cluster Manager。

5層：交易的完整性（Transaction Integrity）

使用5層災難恢復方案的業務，要求保證生產中心和數據備份中心的數據的一致性。在此層方案中只允許少量甚至是無數據丟失，但是該功能的實現完全依賴于所運行的應用。

5層除了使用4層的技術外，還要維護數據的狀態-要保證在本地和遠端數據庫中都要更新數據。只有當兩地的數據都更新完成后，才認為此次交易成功。生產中心和備用中心是由高速的寬帶連接的，關鍵數據和應用同時運行在兩個地點。當災難發生時，只有正在進行的交易數據會丟失。由于恢復數據的減少，恢復時間也大大縮短。數據庫的數據復制功能一般可以工作在這樣的方式下：IBM-DB2-HADR、ORACLE-ORACLE-Replication等。

6層：少量或無數據丟失（Zero or little data loss）

6層災難恢復方案可以保證最高一級數據的實時性。適用于那些幾乎不允許數據丟失并要求能快速將數據恢復到應用中的業務。此種解決方案提供數據的一致性，不依賴于應用而是靠大量的硬件技術和操作系統軟件來實現的。

這一級別的要求很高，一般需要整個系統應用程序層到硬件層均采取相應措施。

1）應用程序層采用基于交易（TRANSACTION）的方法開發。

2）數據庫可以采取數據復制。IBM-DB2-HADR、IBM-INFORMIX-HDR、ORACLE-ORACLE-DATA GUARD等。

3）操作系統使用集群軟件、站點遷移軟件、數據復制軟件：IBM-HACMP、VARITAS-Global Cluster Manager等。

4）硬件層使用同步的數據復制：IBM-ESS-PPRC、IBM-DS4000-RM、EMC-SRDF 或使用帶有CONSISTANCY-GROUP功能的異步數據復制IBM-ESS-PPRC、IBM-DS4000-RM。

7層：解決方案與具體業務相結合，實現自主管理(Highly Automated , Bussiness Integrated Solution)

7層災難恢復方案在第6層的基礎上，集成了自主管理的功能。在保證數據一致性的同時，又增加了應用的自動恢復能力，使得系統和應用恢復的速度更快、更可靠（按照災難恢復流程，手工操作也可實現整個恢復過程）。

7層可以實現0數據丟失率，同時保證數據立即自動地被傳輸到恢復中心。7層被認為是災難恢復的最高級別，在本地和遠程的所有數據被更新的同時，利用了雙重在線存儲和完全的網絡切換能力。7層是災難恢復中最昂貴的方式，但也是速度最快的恢復方式。當一個工作中心發生災難時，7層能夠提供一定程度的跨站點動態負載平衡和自動系統故障切換功能。現在已經證明，為實現有效的災難恢復，無需人工介入的自動站點故障切換功能需要一個應該納入考慮范圍的重要事項。

3.3如何選擇最優的災難恢復方案

在選擇解決方案時，非常重要的一點是，解決方案所需的投資在IT商業價值中應占切實可行的部分，任何人都希望用較少的投資換取更多的利益--災難恢復解決方案的投資一定要少于災難本身帶來的財政損失。

按照下述目標，為一個商業應用選擇解決方案時，決定起來就會簡單：

（按用戶的投入、希望恢復的速度等目標來選擇，災難恢復越快所需的投入就越多）* 恢復時間目標（RTO – Recovery Time Objective）沒有應用系統，可以忍受多長時間？

* 恢復時間點目標(RPO – Recovery Point Objective)系統恢復后，可以允許重新創建多少數據？

* 降級操作目標（DOO – Degraded Operations Objective）數據中心減少了，會有什么負面影響？

* 網絡恢復目標(NRO – Network Recovery objective)網絡切換需要多長時間？

通常，構成應用業務連續可用性的因素只適用于同一機房內的環境。機房本身就是一個單點故障。為了抵抗災難，我們必須選擇一種比連續可用性考慮更多的恢復方案。

恢復方案一定是在全面衡量了實施費用、維護費用、災難對財政的影響，并對業務影響進行了分析后而得出的一個綜合方案。

3.3.1四個關鍵目標

每一層災難恢復方案的恢復時間通常是指恢復處理業務服務所需的安裝時間。然而在現實的災難中，需要對其他更多的事項進行考慮。例如，有些業務可以容忍較長時間的停機服務，但要求一旦業務開始就需要使用最多的實時數據；有些業務必須在盡可能短的時間內恢復服務，而不考慮數據的實時性；還有一些既需要最短的時間內恢復服務，也需要最多的實時數據。

通過評估具體場地的實際災難恢復需求，為恢復計劃開好頭。

3.3.2方案成本與業務停止帶來的損失

災難恢復方案的成本是根據以下兩點得出的： * 客戶需要在多快的時間內恢復數據 * 不能繼續業務處理將帶來多少損失

恢復數據所需的時間越少，業務處理服務中斷的時間就越短，所需的方案成本就越多。

另一方面，不能進行業務處理的時間越長，由此帶來的損失就越大。

最優的方案就是，方案成本曲線和業務停止帶來的損失的曲線的交集。成本/時間窗口。

3.3.3與系統體系結構的關系

為了災難保護，需要建立一個可靠并經過驗證的基礎結構，系統的每一級部件都一定要有冗余，這是必須的。

存儲設備級（Storage Device Level）

存儲設備級，是指存儲的物理實體，如磁盤或磁帶機。為了實現設備級的可用性，使用嵌入在設備自身中的功能，這些冗余功能可通過在磁盤中使用備用磁道或在磁帶機中使用特定的寫機制來實現。

存儲服務器（存儲子系統）控制器級

存儲控制器自身的接口用于連接SAN或服務器（Servers）和存儲設備。存儲控制器的內置功能負責所有與存儲相關的執行操作。

* 內置的拷貝功能，如Point-in-Time 拷貝，遠程鏡像 * 內置高可用性機制（冗余、接管Fail over）

SAN（Storage Area Network）級

SAN級的冗余可通過冗余SAN的基本模塊--SAN交換機或使用導向器（Director）來實現。SAN交換機和導向器的主要區別在于可維護性和可用性。導向器類的產品可以在不中斷服務的同時，在線進行Microcode/Firmware的升級。在出現硬件故障時，導向器通常只需更換一個部件。

操作系統中設備驅動程序級

設備驅動程序是存儲設備，服務器的操作系統和主機適配卡之間溝通的橋梁，它負責實施與操作系統中所展示的全部硬件功能相關的操作，并負責與存儲設備之間的通訊，如光纖通道環境中多路徑和通道接管功能。

操作系統級

在操作系統級，通過使用群集技術可以實現操作系統級的高可用性，如 HACMP for AIX，STEELEYE for LINUX 和 Microsoft Windows Clustering。可以考慮將群集技術作為災難保護的一部分。在災難保護方案中群集本身不代表基礎設施。

應用級

要想在應用級實現冗余，在很大程度上依賴于應用的類型。如在三層的SAN環境中，通過使用多個應用服務器（Multi Application Server），應用層可以做到高可用性。如果任何服務器發生故障，加在其上的負載就會被重新分布到其他運行中的服務器上，業務可繼續進行。

功能級

功能級是系統整體架構中最重要的一級，它依賴以下級的可用性： * IT基礎設施架構的可用性（操作系統+服務器+存儲+網絡）* 應用的可用性（應用+數據）+IT基礎設施架構的可用性 * 業務流程的可用性（應用的可用性+外部相關條件）

在規劃災難保護的功能級時必須包括所有外在因素，如不同企業間的相互協作等。

第四章 容災系統的設計過程

災難恢復計劃描述 | 災難恢復計劃項目階段 | 數據收集和關鍵需求分析階段 | 風險分析階段 | 數據保護階段 | 恢復階段 | 測試和培訓階段 | 維護和修改階段 | 選擇災難恢復方案的步驟介紹

容災方案的制定是一個系統的過程，包含一系列的工作及計劃的制訂，包括Business Continuity Planning(BCP)，Business Recovery Plan(BRP)，Continuity of Operations Plan(COOP)，Incident Response Plan(IRP)，Occupant Emergency Plan(OEP)，Disaster Recovery Plan(DRP)等計劃，在此我們主要介紹災難恢復計劃（Disaster Recovery Plan 或 DRP）的制訂過程及方法

相比于其它機構和領域，IT系統更容易受到各種災難的傷害而導致中斷，特別是在許多情況下，關鍵資源可能屬于不可控范圍（如電力和電信），于是有效的災難恢復計劃、履行計劃和對計劃進行有效地測試對于削減系統風險與各種服務的不可用性就顯得非常重要了。為了保證災難恢復計劃的成功，管理者應該做到以下幾點：

1.理解災難恢復計劃的全部過程及其在整個運行連續性計劃和業務連續性計劃過程中的地位。2.制定或復查其應急策略及計劃過程并運用計劃周期要素，包括預備計劃、業務影響分析、備用站點選擇和恢復策略。

3.制定和復查其災難恢復計劃策略，重點在于計劃的維護、培訓以及對應急計劃的演練。4.1災難恢復計劃描述

簡單地講，災難恢復計劃的重點在于IT的恢復，如系統、應用、數據和相關的設施（如網絡等）。災備的主要目標是在事件發生時，能夠保證全部或部分計算機服務的持續可用。災難恢復計劃就是指，在災難發生時需要采取的響應步驟的詳細過程。

災難恢復計劃包含了一系列災難發生前、過程中和災難發生后所采取的動作，災備方案計劃書應該文檔化，并經過充分的測試，以保證災難處理過程中各種操作的連續性和關鍵資源的可用性。

根據災難發生的時段或業務中斷的嚴重程度的不同，一個企業的生存能力也依賴于管理層重建其關鍵業務的能力。一般來講，這些業務功能的重建需要幾年的時間。但是，對于管理層，必須在幾個小時或幾天的時間內重建，確實是一個難題。重建復雜的商業環境要求有一個經過慎重考慮且具體的計劃，以備在災難發生時執行。從這份計劃中我們可以看到，為恢復初始環境，在重建過程中應該采取的步驟。

在一個組織中，災難的發生是不可預測的。對客戶而言，最想知道的事情是災難什么時候發生。系統和工作人員可以應對災難，并對可預知的災難進行反應是最終的目標。換句話說，災難發生時，不需要等待，而只需要確定你的計劃是否可行。

災難發生時，客戶、供應商和員工通常會關心中央處理設備的停機時間。在這種情況下，這些人都沒有什么過分的要求，只關心停機的等待時間，而停機時間的多少則依賴于災難恢復方案。通常，這種停機時間可以分為以下兩個部分： a)服務丟失

表示從災難發生到系統恢復正常所損失的時間。b)數據丟失

表示用戶數據的丟失，也就是說，系統恢復到災難發生前的數據層面，要花費多少時間可以重新工作。

一個組織的大部分收入，如果過分的依賴于生產系統，一旦應用和網絡停機，則將會造成巨額收入的損失。在不同的行業，如果以小時為單位計算收入損失，因災難而造成的收入減少也是不同的，如能源、電信、制造行業和金融部門，造成巨額收入的損失并不驚奇。另外，實際收入損失所占的百分比也和運營的關鍵業務有關系

總之，災備計劃就是要保證災難發生后，能及時地按照一定的策略、過程和技術等方法迅速恢復IT系統、操作和數據。4.2災難恢復計劃項目階段

如何制訂災難恢復計劃，前面的章節中（參看3.1節 業務連續性）給出了指導性的建議步驟。上述步驟中，每一步都包含了相關方面的各項內容。實際上，在制定災難恢復計劃時，我們可以將這些步驟細化為下圖的操作流程。在下圖的流程中，包含了災難恢復計劃的各個階段，并直觀的告訴我們，災難恢復計劃的制定是一個循環往復的過程。

圖1.災備計劃不同階段圖表

對上圖的簡單分析如下，更詳細的內容，將在以下的章節中給出：

1）項目啟動及項目組的選擇

此階段包括取得管理層的正式同意、選擇項目協調人員和項目組成員、信息收集方式的標準化以及項目資源的調度等方面的內容。2）數據收集和需求分析

此階段包括收集業務過程的信息、技術基礎架構的支撐環境、潛在的停機費用消耗、災難類型以及其它公司使用的相應技術和策略等方面的內容。3）風險分析

在風險分析階段，我們將對為達到災難恢復計劃的設定目標收集的數據進行處理，以便對風險以及在可接受的時間范圍內恢復所需要的資源有較深的理解。

作為風險分析的結果之一，災難防范技術的實施可以幫助我們防止可以避免的災難。比如：火災的偵測和防止，不間斷電源系統等。4）數據保護

數據保護是災難恢復計劃中的關鍵模塊。必須清晰、完整地表述出各類數據（記錄、膠片、電子及光學數據等）的保護方法。5）恢復計劃

恢復計劃是指對意外事件所采取的策略及明確的規劃。如替代的系統、網絡和終端用戶。6）培訓和測試

培訓和計劃性的測試可以對所設計的災難恢復策略進行測試，并且提供了一種可以對災難恢復計劃中的不足方面進行發現和修改的手段。7）計劃的維護管理

計劃的維護管理提供了一種機制，可以使災難恢復計劃隨著業務和IT系統架構的改變而改變。下面我們對各個階段給出較詳細的解釋。

項目啟動和項目組選擇的階段可細分為以下幾個主要組成部分： 1 最高管理層的承諾

企業的最高管理層必須支持且參與計劃的制定和協調，以確保災難恢復計劃在本公司內的有效作用。制定一個有效的計劃，必須要有時間和資源的保證，時間就是計劃的制定所需要的時間，而資源則包括預算和人力。2 建立計劃制定委員會

計劃制定委員會負責監控計劃的制定和實施，由公司各個部門的代表組成，關鍵的委員會成員應當包括業務運營經理和數據處理部門經理。委員會還應當定義計劃的適用范圍。委員會的另一個職責是定期把項目信息通知給最高管理層，因為這是一個比較敏感的主題，可能需要花費較多的人力和財力，這些都需要最高管理層來支持。3 范圍

盡管大多數災難恢復計劃只包含數據處理相關的項目，但是一個復雜的計劃也包含數據處理以外的操作領域，如果同時考慮到災難的其它方面，災備計劃涉及的范圍是相當廣泛的。4 假定

制定計劃要考慮的最基本問題就是設想最壞的場景。對運營系統而言，最壞的場景就是主要設備的損壞。計劃的制定就是基于這樣一個前提，每一個災難恢復計劃都基于一組假定的設想。這些假定對計劃所涉及的環境做了限制，這些限制定義了公司準備接受的災難量級，它們可以通過以下問題來識別：

a）哪些設備被破壞 b）中斷的時間是多少

c）哪些記錄、文件和資料需要保護 d）災難發生時，哪些資源是可用的 1）員工 2）設備 3）通訊 4）傳輸 5）后備場地

在制定災難恢復計劃時，可以借鑒以下典型的假定： a）公司主要的生產設備被破壞

b）擁有在可以執行計劃之內的關鍵性功能的員工

c）員工可以被通知到，并且可以到備份地點執行關鍵性的恢復和 重建工作

d）災難恢復計劃是可用的

e）部分計劃可用于恢復相應的環境中斷 f）備份設備是可用的

g）在異地或別的設備中保存有足夠多的備份 h）備份地點可以處理公司的工作 i）公司本地和遠端的通訊鏈路是可用的 j）本地基本的傳輸是可用的

k）災難發生時，供應商應根據承諾對公司提供支持

以上的假定并不包含全部可能性，但在計劃制定的開始階段可供大家參考。5 項目組及其責任 災難恢復計劃可以按照組的形式來制定，特定的任務可以分配給特定的組。意外發生時的公司架構可能與現有的架構有所不同，那時通常是以組為基礎，不同的組負責不同的功能領域，這些組可能包括： a）管理組 b）業務恢復組 c）部門恢復組 d）計算機恢復組 e）損壞評估組 f）安全組 g）設備支持組 h）后勤支持組 i）行政支持組 j）用戶支持組 k）計算機備份組 l）異地數據存儲組 m）軟件組 n）通訊組 o）應用組 p）人力資源組 q）市場和客戶關系組

企業并不需要建立以上所有的這些組，但我們強烈建議與上述的每個組相關聯的功能都能被包含在其中。

根據員工的技能和領導能力，可以將其選入不同的組。一般來講，各組的成員所擁有的技能應與其平時的工作相一致。例如，服務器恢復組的成員應當包含系統管理員。組成員不僅要知道計劃的目的，而且要知道執行恢復策略的過程。考慮到可能會聯系不到某些成員的情況，成員的組建應基于―互有備份‖的原則。同樣，成員也應當了解其它組的目的和執行過程。

每一個組由組長領導，組長要負責本組的運行，承擔同其它組的協調工作，向組員及時傳達需要的信息，并在組內做決定。另外，如果組長不能行使其職能，必須指定代理組長。在災難恢復計劃中，最重要的組是管理組。他們在事故發生時負責協調所有組的工作。管理組一般由高級管理經理負責，如CIO。

以下是各個組的主要職能： a）負責計劃的執行

b）促進與其它組之間的交流，監督計劃的測試和執行 c）所有或是某一個成員可能領導特定的組 d）協調恢復過程

e）評估災難，執行恢復計劃，聯系組長 f）監控并記錄恢復的過程

g）是最終決定優先級設置、各種政策和過程的人

4.3數據收集和關鍵需求分析階段

要確定一個企業的關鍵性需求，每個部門應該將本部門執行的功能文檔化，經過一定的分析來確認部門內部和外部的主要職能。

部門的日操作記錄可以對確定關鍵性需求起到輔助作用。以下是一些輔助問題：

1）如果災難發生而沒有現有的設備和部門架構，部門能運轉多長時間？

2）在部門內，什么任務的優先級最高？（包括關鍵的手工功能和處理）這些任務 被執行的頻率是多少？如每天、每星期或每月等。

3）執行最高級別的任務，需要那些人力、設備、和供應等？ 4）對于關鍵的設備及供應，在災難的環境中應如何替換？ 5）上述這些關鍵信息的替換需要多長時間？

6）部門內有沒有可供參考的手冊和操作步驟？災難發生時這些是如何替換的？ 7）任何供應、設備和操作過程或手冊等，有沒有在異地存放？

8）確定原始文檔的存儲設備和安全性。在災難的時間中，這些信息如何被替代？有沒有更多的地方來保存？

9）當前計算機的備份過程是什么？如何恢復備份？任何關鍵的備份拷貝有沒有在異地存放？ 10）在災難發生后，臨時性的操作步驟是什么？ 11）一個部門的運轉中斷，對其它的部門有什么影響？ 12）依賴于正常運轉的企業以外的服務商和供應商有哪些？ 13）有沒有經過跨部門培訓的人員？ 14）誰負責維護部門的異常計劃？ 15）災難恢復計劃有沒有其它的考慮？

在上述問題的基礎上，我們列出了以下需要進行文檔化的信息：備份地址列表，關鍵電話號碼記錄，通訊目錄，分發記錄，文檔目錄，設備目錄，表格目錄，保險政策目錄，主要的計算機硬件目錄，主要客戶列表，主要供應商列表，計算機硬件和軟件列表，通知列表，辦公用品供應列表，異地存儲地址列表，軟件和數據文件備份和調度，電話目錄等資料和文檔。

關鍵性需求可以通過問卷的方式來獲得，問卷主要是將每個部門的關鍵性工作記錄在案，并找出最小的必備資源，如人力、設備、供應商、文檔等資源。

確定了各部門的關鍵性需求并將其文檔化以后，管理層就可以為各部門在整個企業的災難恢復過程中設置優先級別。每一個部門的操作可以按照下面的方式給出優先級：

1）基本操作（必需）：服務中斷超過一天，將嚴重地危害到公司的運轉。2）推薦操作（關鍵）：服務中斷超過一個禮拜，將嚴重的危害到公司的運轉。

3）其它操作（非關鍵）：這些信息的存在可以方便業務操作，如果 一旦丟失也不會 影響到業務的正常運轉。

根據RTO和RPO的不同，各公司采取的策略也會有所不同。以下是一些通用的標準，可以根據這些標準將應用進行分級：

1）必需：從停機算起，RTO<8小時，RPO在15分鐘以內 2）關鍵：從停機算起，RTO<72小時，RPO從停機的那一天開始 3）非關鍵：從停機算起，RTO<168小時，RPO48小時以內

4.4風險分析階段

計劃小組負責準備風險管理的流程和業務影響的分析（Business Impact Analysis）。它們包括一定范圍內的災害，如自然、技術或人為的災害。

針對于幾種假定的災難設想，企業的每一個職能領域都應當分析和判斷相應的潛在結果和影響，在風險分析階段還將評估關鍵文檔和重要記錄的安全性。

在多樣的中斷過程中，IT系統更容易受到損害。作為企業風險管理的一部分，有些風險是可以通過技術、管理和操作執行方案來避免的，但不可能避免所有的風險。災難恢復計劃就是一種用來彌補這些風險管理和安全操作不能涉及的災難的高可用性方案。由此看來，災難恢復計劃可以提供一種緊急事件發生后的快速恢復手段。

4.4.1風險管理過程

風險管理過程范圍廣泛，包括確定、控制和減輕IT系統的潛在風險。從風險管理的行為分析，可以分為兩個大的主要功能：

1）通過減少或消除風險，進而避免或減少破壞性的事件。這些措施主要是對從自然、人為和技術方面的威脅進行的安全控制，從而減少或消除風險。

2）降低或限制災難對系統造成的后果。主要措施是預估可能的事件，并在相應的事件 發生后采取相應措施，建立基本的災難恢復計劃。

下圖示意了預先采取安全控制和災難恢復計劃實施的事件間流程：

4.4.2商業影響分析

商業風險分析是災難恢復計劃過程中的重要步驟，隸屬于風險分析階段。這一過程集中分析系統需求、過程及其內部的依賴關系，并使用這些信息判斷可能意外發生的事件及其優先級，圖示為風險分析的示例過程：

上圖的示例分為三個過程： 1）確定關鍵資源

2）確定中斷的影響及允許的停機時間 3）設計恢復的優先級

4.4.3建立可靠的系統

業務恢復計劃的目的是保證員工和設備在災難發生過程中的安全。風險分析的主要目的之一是確定在任何時候應采取的正確防范措施。對災難的防范和準備工作應從企業的最高管理層開始，管理層的支持體現在對先進的安全和風險防范技術的選擇，以及對未知風險的準備等方面。災難預防技術包含兩個方面：流程方面的預防和物理方面的預防。流程方面的預防

流程方面的預防與日常的操作相關，主要是操作規則的定義，相關主題為安全和恢復。流程防范是同每一個員工的行為相聯系的，公司為每一個員工分配相應的職責。流程防范的目標是針對于不同的災難類型定義相應的操作，并使得這些操作成為規則 物理方面的預防

從場所的建造就開始為災害做準備，包括為建筑物配備特殊設備。如為不同的設備配置火災保護。這些特殊的考慮包括：計算機區域設置，火災偵測裝置和滅火裝置，記錄保護，空調設備，熱敏和通風設備，電子供應系統和UPS系統，雙路電源保護，突發事件過程和檔案系統。

4.5 數據保護階段

數據保護是指在公司內部為保護公司資產、確保記錄的準確性和可靠性以及操作的有效性而采取的措施。可以從履行保險和分類記錄各種信息兩個方面來考慮。

4.6 恢復階段

恢復計劃是一種主要考慮在災難發生后，如何快速有效的恢復IT系統的策略，策略的制定應當考慮商業影響分析中所涉及的風險，而且在系統設計和實施的階段中，它與系統的架構設計相集成。在設計恢復計劃時，應考慮下面的情況： 1）系統恢復

系統恢復應針對于關鍵應用主機，如集中式和分布式 2）網絡恢復

網絡恢復計劃主要針對以下方面：

a）關鍵商業應用系統的內部局域網和網絡設備的支持 b）外部廣域網和電信服務

c）待恢復系統和終端用戶間的通訊 3）啟動各災難恢復小組

災難恢復管理組負責協調恢復過程中所涉及的各個項目組。在異常情況下，準確快速的決定會起到關鍵的作用。管理組將負責包括財務決定在內的所有決定。成功的災備計劃，即使在關鍵的成員不能工作的情況下，也可以恢復并維持業務的運轉。4）最終用戶恢復

最終用戶的恢復計劃，在傳統的災備計劃中常常被忽略掉，合理的災備計劃為終端用戶提供了一種可工作的機制

4.7測試和培訓階段

災備計劃的測試是災備方案準備過程中的一個關鍵要素。測試可以暴露災難恢復計劃的不足之處，測試也可以幫助我們評估計劃執行人員的快速響應能力和效率，災難恢復計劃的每一個要素都必須測試，保證其恢復過程的準確性。測試包含以下幾個方面： a）從備份磁帶恢復系統

b）執行恢復計劃的各項目組之間的協調 c）內部和外部的互連

d）使用備份設備時的系統性能 e）正常業務操作的恢復

這里所推薦的測試過程是讓災難恢復計劃的關鍵人員重復執行災難恢復計劃，這樣做可以不斷更新文檔，并修補可能的遺漏，以保證即使主要人員休假，災難恢復計劃也可以執行。

培訓是對測試過程的補充，主要目的是明確災難恢復計劃中各成員的責任，培訓內容包括： a）計劃的目的

b）跨項目組的協調和溝通 c）匯報制度的流程 d）安全要求

e）項目組特有的流程 f）成員的責任 4.8 維護和修改階段

災難恢復計劃應反映系統的需求、執行的流程和規則。因為商業需求、新技術的不斷升級以及新的內部和外部規則的變化，IT系統也會隨之改變。所以，要確保災難恢復計劃的有效性，就必須定期的檢查和修改計劃。一般來說，當每年或當計劃涉及到的內容有重大改變時，災備計劃需要作相應的檢查，而有些內容更需要作頻繁的檢查，如人員的聯系途徑等。以下是至少需要定期檢查的幾個方面： a）運行環境要求 b）安全要求 c）技術程序

d）硬件、軟件和其它的設備 e）各項目組的成員名稱及聯系方法 f）關鍵信息記錄（電子或書面文檔）

4.9選擇災難恢復方案的步驟介紹

本節主要介紹制訂災難恢復方案的簡單過程，僅供參考。

1）按照一定的順序詢問特定的問題

按照一定的順序，詢問一系列與商業災備需求相關的問題，通過這些問題，可以確定災備方案的基本環境、基礎構件及期望的恢復時間。以下提供一些基本的問題，部分問題答案的給出需要基于風險評估和商業影響的分析。另外一些問題則需要運營部分基于其IT基礎架構給出答案： a)哪個或哪些應用需要恢復？ b)應用運行的平臺是哪些平臺？ c)期望的RTO是什么？ d)災備實施場所之間的距離？

e)連通方式，或者在災備地點傳輸數據的基礎架構的傳輸 方式是什么？帶寬是多少？

f)有沒有特殊的硬件和軟件的配置需要恢復？ g)RPO是什么？

h)需要恢復的數據量有多少？

i)期望的災難恢復層次（計劃/未計劃/交易集成）？ j)誰來設計災備方案？ k)誰來實施災備方案？

以上并不是所有可能的問題，但這是一個很好的開始，你可以設計其他一些問題，這些問題是如何使用的呢？參考下圖：

以上模型稱為沙漏模型，在沙漏瓶頸以上的問題定義了基本的業務和IT需求，這些基本的問題必須有充分的答復，因為任何問題的缺少都意味著我們要投資的方案可能會沒有正確的評估。采用這樣的方式，在災備方案實施前可確保收集到正確的業務和IT基礎架構的需求。

我們必須保證這些問題的答案已經廣泛征求了企業管理部門、商務部門、應用組合IT維護組的意見。

2）使用層/RTO（Tier/RTO）和恢復的層次定位災備方案的子集

現在我們可以定義初步的方案，注意：在災難恢復的七層中，一層總是建立在前一層的基礎之上。對應于計劃停機、非計劃停機和交易一致性，相應的災備技術和方案也有所不同： 計劃停機：這一方案只有助于計劃中的停機或者數據移植，對非計劃的停機沒有作用。非計劃停機：在硬件和數據一致性的層面，這一方案有助于非計劃停機的恢復，也意味著支持計劃停機。在應用和數據庫層面，這一層次的恢復不支持交易一致性的恢復。

交易一致性：對于非計劃的停機，方案要求在應用和數據庫交易一致性的層面提供恢復的能力。這一方案隱性要求硬件層次支持計劃停機和非計劃停機。

確定了合適的恢復層次、結合RTO、參考下圖，可以很快的確定需要的災難恢復方案。

3）排除非方案的東西

現在我們通過把第一步中收集到的問題答案應用于候選的方案并剔除不合適的方案，來定義初步、候選的災難恢復方案。請參考下圖：

通過第一步中獲得的問題答案，如距離、不支持的平臺等，可以剔除不符合要求的方案。

如果在這一步驟完成后存在多個災備方案，這都是正常的，它們都是可用的方案。

4）將確定的方案提交給評估組

經過第三步后，將一組初步的災備方案和可用的技術提交給資深的評估組，這個組由一些資深的成員組成。他們將詳細的比較和分析這些備選方案，同時對有效的候選方案注明所需要的技能。

評估組需要充分詳細的配置每一個候選方案。最后，評估組將決定最終選擇最合適的災備方案。

第五章 典型方案介紹

基于軟件的數據備份技術 | HACMP高可靠性災備方案 | 基于磁盤系統的PPRC數據級災難備份解決方案

5.1 基于軟件的數據備份技術

在應用軟件進行災難備份的解決方案中，應從下面三個層次考慮： 用戶應用程序

客戶機軟件 數據庫引擎

其中用戶應用程序和客戶機軟件一般不包含關鍵數據，幾乎所有數據都由數據庫引擎管理并放置在數據庫服務器中。在這三者之中，數據庫中的數據保護最為重要。

一般情況下，用戶應用程序和客戶機軟件只需要將其執行代碼和參數配置文件做以備份，當災難發生時，可以通過這些備份重新安裝和配置用戶應用程序和客戶機軟件。

對數據庫的備份，如果采用硬件級災難備份有兩種方法：一是采用備份的方法，即定期地將數據備份到硬盤和磁帶/磁帶庫上，這些磁帶可以通過運輸的方式運到遠程，以防磁帶在本地的災難中發生毀壞。這種方法的缺陷是實時性較差，恢復時間較長；另一種做法就是硬件鏡像的做法，這種做法在硬件的投資上較大，對兩點間的網絡帶寬有較大的要求。那么，有沒有一種兩者兼顧的解決方案呢？數據庫產品提供的數據庫復制技術就是一種兩者兼顧的災難備份解決方案。在前面提到的災難恢復方案的7個層次中屬于第5或第6層次。

數據庫復制技術在數據庫級別的災難備份解決方案中可以實現遠程容災。目前已有的產品有IBM DB2 HADR、IBM INFORMIX HDR以及ORACLE DATA GUARD。

IBM DB2 HADR是High Availability Disaster Recovery 的縮寫，HADR 將HA（高可用性）和INFORMIX DR的技術緊密結合起來。INFORMIX HDR是High Availability Data Replication的縮寫。

HDR的工作原理是通過將主數據庫服務器（簡稱為A）的邏輯日志緩沖區復制到備份數據庫服務器（簡稱為B），而且能在主數據庫服務器操作失敗時自動切換到備份數據庫服務器。復制方式有同步方式和異步方式兩種。我們將在下面詳細介紹HDR的工作原理以及同步方式和異步方式。

正常狀態下，主數據庫服務器做數據庫的讀寫操作，備份數據庫服務器為只讀方式。當主數據庫服務器失敗時，備份數據庫服務器會自動接管主數據庫服務器的事務處理。此時，備份數據庫服務器作為主數據庫服務器進行數據庫的讀寫操作。當主數據庫服務器被修復后，主數據庫服務器作為新的備份數據庫服務器。

此時備份數據庫服務器雖為只讀方式，但并不是空閑的。它可以分擔主數據庫服務器的負載，例如執行查詢、出報表等任務。

數據庫復制對硬件的要求相對較低，只要主數據庫服務器和備份數據庫服務器的硬件配置相同即可，不是必須使用高端存儲設備，例如IBM ESS等。主數據庫服務器和備份數據庫服務器的距離不受限制，而且對網絡的壓力并不大，但需要更強的數據庫管理能力。

下面介紹一下HDR的工作原理。如下圖所示：

在邏輯日志緩沖區（Logical Log buffer）刷新之前，它里面所有的交易（Transaction）將拷貝到數據復制緩沖區（Data Replication Buffer）。數據復制緩沖區的大小和邏輯日志緩沖區相同。數據復制緩沖區通過TCP/IP網絡將數據發送到備份數據庫服務器的數據復制緩沖區中。在備份數據庫服務器端，一個數據復制線程接收數據復制緩沖區的數據并把他們放入到恢復緩沖區（Recovery Buffer）.另一個數據復制線程（或一些線程）記錄數據庫日志信息。主數據庫服務器和備份數據庫服務器都有一個―Ping‖線程在運行，它會定時喚醒并且檢查兩個數據庫服務器的連接。如果任何一臺服務器上的―Ping‖線程檢測到連接中斷，都會發一條出錯信息到消息日志中。

HDR有兩種復制方式：同步方式（Synchronous）和異步方式（Asynchronous）

在同步復制的方式下，主數據庫服務器的邏輯日志緩沖區只有在下面的過程完成后才可以刷新：

1.Copy: 邏輯日志緩沖區數據拷貝到數據復制緩沖區；

2.Send: 數據從主數據庫服務器的數據復制緩沖區通過網絡傳送到備份數據庫服務器； 3.Acknowledge:當備份數據庫服務器接收到數據后發回確認信息； 4.Flush: 此時，主數據庫服務器才可以刷新其邏輯日志緩沖區的數據。

采用同步方式的優點是兩邊數據庫服務器的數據一致，但是由于每筆在主數據庫服務期提交的交易需要發送到備份數據庫服務器而且得到確認后才算真正成功完成，由此而產生的時間延遲會使性能受到一定的影響。

如果采用異步復制方式，主數據庫服務器的邏輯日志緩沖區只要在邏輯日志緩沖區的數據拷貝到數據復制緩沖區之后就可以進行刷新了。這樣做的缺點是在某些系統失敗的情況下，可能會有一些數據還沒有來得及通過網絡傳送到備份數據庫服務器；優點是主數據庫服務器的性能不受影響。

對于Oracle DATA GUARD的工作原理，大致上與IBM HADR 和INFORMIX HDR的工作原理類似。

Oracle9i DATA GUARD 通過使用稱為備份的數據庫來防止數據災難的出現。它通過將源數據庫的重做日志傳輸并應用到備份數據庫中，來使備份數據庫與源數據庫同步：

可以將重做日志直接從源數據庫同步的寫到備份數據庫，來完成零數據損失的災難保護，這會給源數據庫的性能帶來一定的性能損失。

可以將歸檔的重做日志從源數據庫異步的寫到備份數據庫，來使源數據庫在極少的損失性能的前提下，最小化地減少數據的丟失。

如果重做日志數據到達備份數據庫后就快速應用到備份數據庫，則在源數據庫出現問題時便可以快速地切換到備份數據庫。然而，如果延緩一定時間后再應用重做日志數據，就可以避免源數據庫的錯誤快速地傳播到備份數據庫。

DATA GUARD同樣也有同步和異步復制兩種方式可以選擇。

5.2 HACMP高可靠性災備方案

HACMP容災系統在世界范圍內廣泛應用，具有以下鮮明的特點：

簡單易用，7x24小時集群應用技術

顯著減少停機時間，允許不間斷的進行集群升級和系統維護 提供多種數據備份和恢復途徑，以滿足災備的需求

HACMP經過十多年的發展，從5.1版本開始，增加的一項新的功能HACMP/XD支持ESS/PPRC和基于IP連接的遠端故障切換。

5.2.1 A.HACMP方案 a)介紹

HACMP對關鍵應用提供良好的保護，提供可信賴的高可靠性服務、監控能力和對應用的失敗監測，切換應用環境到備份主機。借助于HACMP/XD功能，也可以將應用切換到遠端備份機器。在集群中，HACMP使用冗余的硬件配置以保持應用的正常運行，在需要時將應用切換到備份主機，最多可以有32臺服務器組成HACMP集群。HACMP也可以監測應用的錯誤，但這些錯誤應當不足以影響到系統的正常運行，如進程失敗、系統資源消耗過大等。對這些錯誤事件，HACMP監控、發現并采取相應的措施以保證系統的運行。HACMP可配置為響應幾百個系統事件。

事實上，使用HACMP可以防止一些計劃中的停機，如在停機維護的過程中，用戶、應用和數據可以轉移到備份主機。HACMP可以滿足復雜的、各式各樣應用的可靠性及其恢復的需要。

b)優勢

HACMP充分利用了AIX操作系統的優點，并拓展了AIX系統和網絡的管理功能，提供了橫向和縱向的靈活性。c)功能增強

IBM HACMP在5.1的版本中，功能進一步增強，這些新的功能包括： 1)使用快速硬盤接管技術，減少切換時間，限制在10秒鐘之內

2)使用流水式配置界面，僅僅需要六次輸入就可以配置一個簡單的 HACMP集群 3)基于硬盤的新的非IP心跳信號保護技術，不需要額外的硬件支持 4)增強的安全機制，剔除了對.rhosts的要求

5)增加快速的集群配置確認和同步技術，提高管理的效率 6)在集群的監控中提供更多的集群狀態信息

7)增加災難恢復技術，保證在災難發生時系統是可控制的

5.2.2 B.HACMP/XD

在災備方案中，如果需要在異地做數據鏡像，HACMP/XD（Extended Distance）是必選的功能。對中小企業而言，HACMP/XD的高可靠性解決方案是極具吸引力的，從成本上看，也是可以負擔的。在關鍵的商業應用中，高可靠性是最基本的功能。

HACMP/XD提供了多項技術以滿足遠距離的數據鏡像、切換和信息同步：

a)支持IBM企業級存儲服務器ESS的PPRC，即HACMP/XD over PPRC。這允許HACMP集群自動的切換PPRC鏡像組（PPRC pairs）中的硬盤，可以設計基于ESS PPRC的強大的容災方案。HACMP/XD結合PPRC，可以保證集群環境中關鍵數據始終可用。

下圖為HACMP/XD PPRC方案的示意圖：

b)HACMP/XD基于IP的鏡像，提供遠端數據鏡像，沒有距離限制，集成使用HAGEO 的技術。基于IP的鏡像技術，允許HACMP集群中的pSeries UNIX服務器放置在任意位置，每臺服務器都維護一份精確的應用和數據拷貝。HACMP/XD提供數據的同步、切換和恢復。HACMP/XD基于IP的數據鏡像是基于存儲介質的邏輯層來實現的。也就是說，本地的數據可以使用RAID或本地鏡像保護。

HACMP/XD, HAGEO技術環境是一個分布式的集群，可以分布在兩個足夠遠的地方，通過冗余的點對點的TCP/IP網絡連接，提供應用數據的恢復功能。下圖為HACMP/XD:HAGEO的集群示例：

對關鍵的商業應用和數據，每一個場所都維護一份實時鏡像。因而，如果某一場所遭到破壞，HACMP/XD:HAGEO將自動切換和同步，可以保證生產系統在較短的時間內恢復運行。使用HACMP/XD功能，需要具備以下條件：

i.HACMP V5.1.0(cluster.es.server.rte 5.1.0.0)或以上版本 ii.結合使用ESS/PPRC鏡像：

操作系統AIX 5L Java 運行環境1.3.0.15, 或以上版本 IBM ESS 微碼 2.1.1, 或以上版本

IBM 2105 命令行接口（Command Line Interface，ibm2105cli.rte32.6.100.13）或者IBM 2105命令行接口（ibm2105esscli.rte 2.1.0.15）

注意：假定以上命令行接口命令安裝在其缺省的目錄下/usr/opt/ibm2105cli IBM 2105 子系統設備驅動程序（Subsystem Device Driver），ibmSdd_510nchacmp.rte 1.3.3.6, 或以上版本 iii.使用基于IP的鏡像：沒有特殊要求

5.3 基于磁盤系統的PPRC數據級容災解決方案

本節介紹的基于磁盤系統的PPRC（Peer-to-Peer Remote Copy）數據級容災解決方案，是災難恢復方案的7個級別中的第六個級別，可以保證少量或無數據丟失，實現最高一級數據的實時性，適用于那些幾乎不允許數據丟失和要求能快速將數據恢復到應用中的業務。此種解決方案提供數據的一致性，不依賴于應用而靠大量的硬件技術來實現。

目前業界有兩種基本的基于磁盤系統的遠程拷貝形式：

同步PPRC遠程拷貝(synchronous writes)：來自主機的數據被寫往本地連接的磁盤系統，該系統將數據轉發給遠地點連接的磁盤系統。只有當兩個系統都擁有數據的拷貝以后，本地系統才會向主機返回一個I/O完成指示。同步遠程拷貝能夠在遠地點提供最新的數據，但應用程序會因等待寫I/O操作的完成而被延遲。由于距離的限制這種方式也叫做―同城鏡像(Metro Mirror)‖

異步PPRC遠程拷貝(Asynchronous Write)：來自主機的數據被寫往本地連接的磁盤系統，該系統立即向主機返回一個I/O完成指示。數據在很短的一段時間(在實際中通常在數秒鐘到一分鐘左右)以后被送往一個遠程磁盤系統。異步遠程拷貝對應用程序性能的影響最小，但遠程磁盤系統在數據的更新程度上與本地系統相比會有一個延遲。

單純的異步拷貝由于線路距離較遠等原因，本地磁盤和遠地磁盤可能會有邏輯卷讀寫順序上的差異。這種方式也叫做―全局拷貝(Global Copy)‖

在全局拷貝(Global Copy)的情況下，比如本地磁盤系統提供給主機5個邏輯卷，某一時刻主機對這些邏輯卷發起了A，B，C，D，E，5個寫盤請求，本地的磁盤系統的寫順序是A，B，C，D，E。但是由于線路等原因，遠地的磁盤系統在接收寫請求時，收到的順序可能是A，C，B，D，E。寫盤的順序也是A，C，B，D，E。我們假設災難發生在這5個寫操作D，B的中間部分，那么這時遠地的數據C很有可能是沒有意義的，甚至是無理的。

為了解決本地磁盤和遠地磁盤可能存在的邏輯卷讀寫順序的差異，有的磁盤系統提供帶有一致性組的異步遠程數據拷貝。在這種方式下，遠地的磁盤系統會將先收到的寫請求緩存起來(比如上面的數據C)，等到它前面的數據(A,B)到達后，再按照順序寫盤。這種方式也叫做―全局鏡像(Global Mirror)‖。見下圖:

IBM異步PPRC遠程拷貝提供帶有一致性組的異步遠程數據拷貝。下面，分別針對兩種方案在IBM ESS中的實施方案予以介紹。

5.3.1 同步PPRC數據級災難備份方案

IBM的PPRC提供了實現災難備份的方案基礎。PPRC全稱Peer-to-Peer Remote Copy，是以存儲為基礎的實時且與應用程序無關的數據遠程鏡像功能。PPRC的實現較為簡單，是無數據丟失且具有完全恢復功能的災難恢復解決方案。

PPRC基于IBM ESS企業級存儲服務器，以邏輯卷為基本單位，通過光纖通道將本地ESS上的數據同步鏡像到遠端的ESS上。

為了在保證數據的即時性、完整性和系統性能之間達到平衡，PPRC提供了多種工作方式。

同步方式下:點對點遠程拷貝(PPRC)是一種同步遠程鏡像的工具，可用于相隔距離達103公里的兩個ESS系統中指定的邏輯卷。這一距離可以通過第三方提供的通道擴展器加以延長，ESS可以為所有連接的主機支持PPRC功能。

PPRC將確保如果備份卷不能被更新，那么即使源卷更新成功，整個寫操作也會返回失敗---保證源卷和目的卷的數據徹底一致。同步方式可以保證數據不會丟失，更重要的是數據的一致性在這種方式下能夠得到很好的保證---數據的不一致意味著相關數據的丟失，此時數據庫的數據安全機制無法保證數據的安全，嚴重時有可能造成數據庫無法啟動。

PPRC的同步實現機制如下圖所示：

PPRC同步工作過程為：

1、應用程序將數據寫入磁盤--在生產系統中的應用程序將數據寫到生產系統的磁盤。

2、生產系統中的磁盤數據傳輸到備份磁盤--對每一個在生產系統的寫操作都要將這個寫操作送到備份磁盤。

3、備份機磁盤數據復制--備份磁盤復制生產系統的數據。

4、將寫完的操作信息返給生產磁盤--當生產系統收到備份系統傳回的已寫信息之后，生產機的磁盤系統通知主機該寫操作已完畢，在此之后生產系統的應用將繼續執行。在同步PPRC的建立過程中，卷具有不同的狀態，以保證數據的完整性。

5.3.2 異步PPRC數據級災難備份方案

PPRC + FlashCopy數據備份方案

為了提高PPRC數據備份方案的效率，可以考慮結合IBM公司企業級存儲服務器ESS的FlashCopy功能軟件，采用異步方式實現PPRC數據備份。在異步工作方式下，PPRC能夠在遠端更新沒有完成的情況下，只要本地更新成功，就可以向主機返回―寫成功‖的信號。好處是：在主備機房之間的數據鏈路帶寬成為瓶頸時，采用異步方式可以不影響主機房生產系統的性能。壞處是：

1、數據將有可能丟失；

2、在異步同步不能最終成功完成的情況下，數據的一致性無法得到保證。所以當采用異步方式時，IBM建議先采用IBM ESS的快速拷貝功能FlashCopy備份需同步的數據，再進行數據同步。

ESS的FlashCopy的使用

ESS的FlashCopy提供了一個―時間點‖（Point in time）的拷貝服務功能，從源卷到目標卷快速地復制數據。邏輯拷貝通常可以在數秒內完成，然后就釋放源卷，進行正常工作，而物理拷貝操作在后臺進行。在物理拷貝的進行過程中，拷貝和被拷貝的數據都能被用戶使用。

IBM ESS的FlashCopy支持兩個選項，它提供NO COPY選項來支持災備的應用需求。以下的內容討論了在移動災備的應用環境中是如何使用這些選項的。

FlashCopy COPY選項