第一篇：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選項

第二篇：異地容災方案

某金融機構數據級 異地容災案例

一、概述

備份與容災是存儲領域兩個極其重要的部分，二者有著緊密的聯系。一般來說，備份是指用戶為應用系統產生的重要數據制作一份或者多份拷貝，以增強數據的安全性；容災是用戶為業務系統建立一個或多個冗余站點，達到業務不間斷的目的。因此，我們可以把備份稱作是“數據保護”，而容災稱作“業務應用保護”。備份與容災中都有數據保護工作，備份大多采用近端方式，成本低；容災則采用遠程方式進行數據保護，成本較高。

大體上講，容災可以分為3個級別：數據級別、應用級別以及業務級別。數據級別容災的關注點在于數據，即災難發生后可以確保用戶原有的數據不會丟失或者遭到破壞。數據級容災較為基礎，其中，較低級別的數據容災方案僅需利用磁帶庫和管理軟件就能實現數據異地備份，達到容災的功效；而較高級的數據容災方案則是依靠數據復制工具，例如卷復制軟件，或者存儲系統的硬件控制器，實現數據的遠程復制。數據級別容災是保障數據可用的基礎，當數據丟失時能夠保證應用系統可以重新得到所有數據。本案例容災級別為數據級容災，日后在此基礎上可以進一步部署更高級別的容災方式。

二、實施前狀況及需求分析

本案例實施單位為某全國性金融機構的分支單位，在此簡稱A分支。該金融機構已經實現了全國性的數據集中管理（數據大集中），重要的生產數據已經集中在總部統一存儲管理。而且A分支對于重要的業務中間數據在本地也有IBM 3584大型帶庫進行存儲備份。所以說A分支針對于生產數據的備份和冗災都有了較高級別的保障。

但對于A分支內部一些前置機數據雖然在本地也進行了備份，對于數據安全有一定的保護，但在數據容災方面較為薄弱，由于備份數據與生產環境在同一樓內，數據較為集中，一旦發生火災等大型災難則對數據影響較為嚴重。

因此用戶考慮針對于這些前置機數據部署遠程的數據容災系統。容災地點定在25公里以外，線路采用租賃長波裸光纖，每天的數據量約為（110G），容災級別為數據級容災。

三、系統方案

系統結構示意圖如下：

前置機IBM X3650 備份管理服務器p5TSM備份軟件lanp5前置機光纖鏈路IBM SAN 交換機IBM SAN 交換機p5lanIBM T3200 磁帶庫IBM DS3400 存儲DS4100前置機TotalStoragep51011121314SAN存儲備份區域A分支異地容災區域A分支機構區域A分支異地數據容災系統結構示意圖A分支異地容災系統線路采用長波裸光纖，帶寬可根據需要在線路兩端架設網絡設備的速率而定，根據A分支每日數據備份量（約為110G），若按100M網絡線路負載80%計算，每天傳輸時間約為3小時。所以A分支的數據容災系統可以采用直接將存儲備份設備及備份管理服務器放置在遠端的方式進行數據備份和管理。

硬件方案：在備份服務器上，本案例選用的是IBM X3650服務器，針對于備份管理服務器對運算方面要求不高，所以服務器配置單個4核2.0 CPU，為了增加本地數據存儲量服務器配置了6塊300G熱插拔硬盤，另外服務器配置了IBM RAS II遠程管理卡可以方便的進行遠程控制管理，解決了服務器遠程管理維護的問題。

存儲及備份設備選用IBM DS3400（光纖通道）磁盤存儲和TS3200（光纖通道）磁帶庫建立了SAN存儲區域。這樣為日后存儲系統的擴展和備份系統實現統一管理建立了良好的平臺。

備份管理軟件選用IBM Tivoli Storage Manager,由于A分支的遠程容災數據為本地已經的打包好的數據不涉及數據庫，所以在備份模塊上只使用了最基礎的文件備份模塊，而且將服務器端和客戶端同時裝在X3650服務器上進行備份操作。

如上圖所示，需要備份數據的前置機先將數據在本地打包，然后發送到遠端的IBM DS3400存儲上，然后再根據策略將需要永久保留的數據備份到磁帶庫中的歸檔存儲池中，將只需要保存一份最新版本的數據循環保存到磁帶庫的循環備份存儲池中。在DS3400存儲上也保留了數據的最新2到3個版本，用腳本按時間對存儲上備份的數據進行清理。

在遠程管理方面，在遠程服務器上安裝遠程監控軟件（LINUX 系統采用VNC遠程管理軟件，WINDOWS系統采用遠程桌面即可），再安裝上IBM ServeRAID 管理軟件就可以對本機和IBM DS3400存儲的陣列和磁盤進行遠程管理了。同時也可以使用IBM TSM備份管理軟件和磁帶庫的管理軟件對磁帶庫進行遠程管理。這樣整個系統基本上都可以在遠程監管的范圍內了。結合IBM RAS II遠程管理卡可以進一步對服務器進行遠程開關機及設置BIOS信息等操作，使遠程管理更為方便。

用戶使用評價：

項目使用了TSM軟件結合LINUX 腳本實現了自動備份，達到了遠程數據級容災的目的，使得數據更可靠，同時也減輕了系統管理員的工作量。系統實施后達到了預先期望要求，對工程很滿意。

第三篇：容災備份建議書（推薦）

醫院信息系統容災備份建議書

一、概述

二十一世紀的醫院已經逐漸發展為現代化的綜合性醫院，為了實現醫院管理的科學化、現代化、數字化，與國際、國內信息化建設的新技術接軌，適應現代化醫院的醫療、科研、教育和管理的要求，現代化的醫院所建立起的信息系統(HIS)主要以一體化的臨床系統、LIS系統、PACS系統，EIS系統、PIS系統等為基礎，實現數據全面共享，共同形成全面的醫院信息管理系統。龐大的系統必然產生海量數據，對于軟件系統而言數據就是根本，任何操作、分析、結算等等都從數據庫中提取。從某種意義上說，數據安全成為了現代醫院信息系統安全的重中之重。一旦數據丟失，對任何一家醫院來說都會產生重大的影響。

二、項目立項的必要性及市場需求分析

近幾年，國家各部委對數據信息安全都有相關的明確規定！頒布了如下一系列條例，如《國家信息化領導小組關于加強信息安全保險工作的意見》，《計算機信息系統安全保護條例》、《信息安全等級保護管理辦法》、《2006―2020年信息化發展戰略》、《信息系統災難恢復規范》、《保險業信息系統災難恢復管理指引》、《銀行業信息系統災難恢復管理規范》、《民用航空重要信息系統災難備份與恢復管理規范》、《重要信息系統災難恢復規劃指南》。在2010年11月，北京衛生局聯合公安局等部門下發了《關于開展信息安全等級保護安全建設整改工作的實施方案》的通知，該通知中也明確提出了數據備份的安全等級保護，并要求需要在重點單位發揮試點示范作用。由此可見各行業已經開始注重容災備份的重要性了！

對于關乎國計民生的醫院行業，政府更是大力監管，在2011年推出的“《三級綜合醫院評審標準（2011 年版）》（衛醫管發〔2011〕33號）”文件中的第五大點第四條就明確規定了“實施國家信息安全等級保護制度，實行信息系統操作權限分級管理，保障網絡信息安全，保護患者隱私。推動系統運行維護的規范化管理，落實突發事件響應機制，保證業務的連續性。” 該部分就已經包含了容災備份及業務連續性管理的要求，從等級保護的要求而言，二級及以上的等級保護也是要求要做備份及業務連續性管理的，還需要有應急的制度、程序流程和災難演練。

醫院信息系統運行中可能出現的突發性故障和問題

１、系統硬件故障

如數據/系統磁盤的損壞將導致數據不能訪問，并進而可能導致應用進程終止或系統停機，甚至系統不能重啟動；網卡的損壞可使終端用戶無法訪問系統服務；CPU或內存的失效則會導致系統的死機；

2、應用程序或操作系統出錯

由于操作系統或應用程序中可能存在不完善的地方，當碰到某種激發事件時，應用程序非正常終止或系統崩潰；

3、人為錯誤

一些人工的誤操作，如刪除系統或應用文件，終止系統或應用服務進程，也會導致數據丟失或者系統服務的無法訪問；

4、電腦病毒/黑客入侵

由于目前的大多數計算機系統直接或通過U盤等硬件設備間接地連接在網絡上，若缺少有效的防范機制，很容易遭受病毒的感染或黑客的入侵，輕者數據被損壞，重者系統癱瘓；

5、自然災害

由于一些意外的不可抗拒的因素，如雷擊、火災、洪災等導致的計算機系統破壞，將會使一般系統的恢復非常困難和耗時，導致業務系統長時間的中斷。

6、正常的停機

主要指計劃內的系統升級、安裝軟件等過程。

三、相關領域國內外技術現狀、發展趨勢及現有工作基礎

備份的歷史可以追溯到上世紀50年代，那時候國外一些公司就開始對自己的重要數據進行備份保護。但那時候重要數據以紙質媒體為多，電子數據只有一小部分，他們將其副本放置在另一個相對安全的地點存放，防止災難事故對數據的損壞，這便是容災備份的雛形。

70年代的時候隨著電子數據越來越多，這種類似的數據容災保護形式越來越普遍。到了80年代，美國市場上已經有了上百個專業公司。一些視數據為生命且數據量巨大的金融公司開始廣泛的采用這些公司提供的異地災備中心存儲解決方案。

1983年，政府開始對數據安全進行足夠的重視。美國聯邦貨幣監管中心要求金融機構起草了有關數據災難備份及恢復的指導性文件，主要強調數據庫的備份和恢復，通過運送備份磁帶到專門的存儲地實現安全。此文件一直使用到1989年，聯邦貨幣監管中心有了更詳盡更成熟的一套數據安全相關資料

進入九十年代，計算機的迅速發展和普及在大大的提高了生產效率的基礎之上也給再災難行業帶來了新的市場和機遇，更過容災備份廠家和產品有了用武之地。

九十年代的中后期（2000年前后），出現了業務連續性的概念，并開始逐漸取代單純的災難恢復。與災難恢復相比，業務連續性不只局限于傳統的IT系統，而是涵蓋了包括人為操作失誤、網絡故障、流程中斷等。

2000年以后，隨著國內各行業信息系統的快速發展，特別是銀行、證券、保險和政府等行業業務大集中速度的加快，企業的技術風險也相對集中。一旦發生災難，則將導致政府和企業所有分支機構、營業網點和全部的業務處理停頓，或造成企業客戶數據的丟失。如何防范技術風險,確保數據安全和業務連續性，已成為企業急需面對的課題。

雖然國內的信息化建設足足比國外晚了近五十年，但是一直是用一種飛向的速度在追趕。基于此國家相關部門借鑒國外的容災備份理念，對加強信息安全保障工作十分重視，先后出臺了多項有關信息安全保障措施。如中國人民銀行于2002年8月下發了《關于加強銀行數據集中安全工作的指導意見》，指出：“為保障銀行業務的連續性，確保銀行穩健運行，實施數據集中的銀行必須建立相應的災難備份中心。” “業務連續性計劃應報中國人民銀行備案。”。

2003年8月,中辦發[2003]27號文件——《國家信息化領導小組關于加強信息安全保障工作的意見》規定：各基礎信息網絡和重要信息系統建設要充分考慮抗毀性與災難恢復，制定和不斷完善信息安全應急處置預案。“誰主管誰負責，誰運營誰負責”。

2004年9月，信安通（國家網絡與信息安全協調小組辦公室）發[2004]11號文件——《關于做好重要信息系統 災難備份工作的通知》：提高抵御災難和重大事故的能力，減少災難打擊和重大事故造 成的損失、確保重要信息系統的數據安全和作業連續性，避免 引起社會重要服務功能的嚴重中斷，保障社會經濟的穩定，要求“統籌規劃、資源共享、平戰結合”！

同年2004年9月，開始起草《信息系統災難恢復指南》初稿；

2004年10月22日，成立了由國信辦領導、8大重點行業和5個政府單位專家及 萬國數據服務公司組成的《指南》工作組；

2005年4月，國信辦以文件的形式下發了《信息系統災難恢復指南》；

2006年5月，信安標委專家討論，按照國家標準的要求調整《指南》的內容，形成征求意見稿；

2006年6月20日，召開信息系統災難恢復國家標準工作組會議。根據意見，《信息系統災難恢復指南》更名為《信息系統災難恢復規范》；

2006年9月12日，信安標委召開WG7工作組標準項目投票工作會議，一致通過 成員單位投票，經過對《規范》的再次修改，形成《規范》的送審稿修改稿。

2007年7月30日，《信息安全技術 信息系統災難恢復規范》發布；2007年11 月1日實施，將災難恢復能力分為七個等級，成為國標。

由此可見，信息系統安全和災難備份已經引起了國家、社會、企業的高度重視，災難備份業務的發展是客戶保持業務連續運作的需要，同時也是社會的需要和政策法規的要求，是市場發展的必然。

在這個大環境下，國外的廠商蜂擁而入。Veritas、CA、Falconstor(飛康)、Bakbone、Commvault這些軟件公司巨頭很快的占據了國內容災備份市場的半壁江山。而更早進入中國市場的硬件巨頭們，眼饞這塊大蛋糕，也很快的伸出刀叉，通過自主研發或者兼并收購等模式很快的擴充了自己的產品線，提供軟硬結合的產品，通過軟件為硬件增值，通過硬件為軟件鋪路。如IBM的TSM（Tivoli Storage Manager）系列；HP的DP（Data Protector）系列；EMC收購Legato以后推出的Network系列。這些99%來自美國的產品，很快的瓜分了國內的容災備份市場。如此這般，國內數據安全的命脈竟幾乎全部掌握在了國外產品的手中，我們的使用者竟心安理得，殊不知這種潛在的威脅將是致命的。當年美伊戰爭時，伊拉克從法國買的防空系統打印機都被美國植入了木馬芯片，以至于在后來的“沙漠行動”中，美國飛行員像在家里玩電子游戲一樣自由自在地來來去去。

歷史總會重演，如果我們不引起足夠的重視，下一個目標可能就是我們。何況美國現在在抵制我國的華為、中興產品，認為這些產品威脅到了他們的信息安全，而我們卻還在瘋狂的購買iphone，肆無忌憚的使用國外的軟件來備份自己的核心數據，這會讓我們一不小心就成了賣國賊。

也許有人會說，是因為國內的軟件不爭氣，我們才使用國外的產品。但這只不過是一種推脫責任的借口。想我中華泱泱大國，民間高手無數，且近幾年在核高基政策的支持和扶持下，軟件產品飛速發展，已經產生了一大批的高新企業和優秀軟件。榆林三院信息系統容災備份現狀

我院信息系統建立在Windows 2008操作平臺上，現有兩臺臺服務器，其上運行了HIS、PACS等系統。這些服務器只作了單一的本地數據存儲，并在指定的時間通過數據命令將數據備份在另一臺PC機中。操作系統是Windows 2008R2 64bit，數據庫系統是Oracle。比如醫院HIS和PACS服務器每天晚上10：00通過ORACLE EXPORT將HIS數據導出成一個DMP文件。如果本地服務器出現硬件故障（CPU、LAN、POWER、FAN等），都將導致醫院部分日常業務中斷，對于依賴計算機管理水平高的醫院來說，很多的業務將無法開展。當ORACLE數據庫出現故障時，對于時間要求嚴格、病人數據大的醫院出現短暫的停頓都無法忍受。如果采用上面所說將DMP文件也入回數據庫中，首先要修復硬件，重裝操作系統，至少需要數個小時甚至幾天才能恢復，并且要丟失好一天的業務數據。

四、項目計劃目標及主要研究內容

理想的容災解決方案通常都具備以下內容

第一、數據的實時備份。RPO(恢復到目標)=0，確保數據零丟失；

第二、數據持續回退，且保證回退點數據完整可用。以便找回誤刪除的數據及在數據不完整時能恢復數據到最近的完整狀態；

第三、本異地容災。將數據實時備份到同城以及異地機房，降低本地機房出現大的事故時候對醫院的損害。

第四、業務連續性管理。原系統不論什么原因出現故障停止對外服務時，備份系統可以在很短的時間接替原服務器對外提供服務，讓系統恢復正常，即RTO(恢復時間目標)≈0,以免影響醫院信息系統業務。

根據對醫院環境和應用特點的分析，我院通過整合存儲架構、采用群集高可用系統、核心數據的集中備份和異地備份、系統容災快速恢復等多種數據安全保護方式，完全消除上述隱患，并可做到系統平滑升級和在線擴容。

具體而言，我院的信息系統的主要需求在以下幾個方面：

1、高性能和高可靠的集中存儲系統：由于有大量的并發訪問，需要對目前的單機存儲架構進行改造，構建一個高效安全的專用存儲網絡，可以把我院的信息系統整合為FC SAN存儲架構。存儲設備采用具備高性能和高可靠性的光纖接口的磁盤陣列，實現數據的集中存儲。磁盤采用高可靠的SAS磁盤或FC磁盤。

2、存儲和備份空間容量要求: 針對上述所有應用系統的服務器實現集中存儲管理，考慮到3-5年的數據增長，集中存儲設備的容量要求達到：醫院需要3TB的存儲容量；集中備份需要至少5TB的可用空間。

3、數據的高安全性：由于HIS、PACS等數據是絕對不能丟失的核心業務數據，因此需要對核心業務數據做冗余的在線和離線數據保護，構建一個完整的數據統一備份系統，將整個網絡中的所有關鍵數據庫數據進行集中備份，建立統一的備份策略，自動備份數據。針對上述的數據庫服務器的數據實現在線備份（包括對SQL、Oracle等主流數據庫的在線備份），數據集中備份到虛擬磁帶庫中，這樣在主存儲設備中的數據出現損壞或丟失的情況下都能夠迅速從虛擬帶庫中得以恢復；另外，對于需要長期保存的數據，可以通過備份到與虛擬磁帶庫直接連接的一臺物理磁帶庫中，實現離線的歸檔。整個數據的備份和恢復，以至于將來可能的數據遷移、數據復制等一系列數據管理操作，都是通過備份軟件來統一管理。因此需要采用技術領先，具備圖形化操作、全中文管理界面，以及支持斷點續傳（尤其是數據庫的斷點續傳）和真正合成全備份的備份軟件。系統設計目標

為上述應用系統建設集中存儲和備份網絡，以及異地的數據容災中心，實現數據的統一安全管理，針對不同應用類型和數據類型提供多重的數據安全保護

手段，在此基礎上確保核心應用的7*24小時連續運行。

存儲系統建設目標：使用高性能、高可靠性的大容量存儲設備，進行存儲整合，通過建立FC SAN存儲基礎架構,使數據集中存儲，建立一個高效、穩定、可靠的存儲網絡、數據存儲中心和安全的管理平臺。備份系統建設目標：構建一個完整的企業級數據備份平臺。將整個存儲網絡中的重要數據進行集中備份，建立統一的備份策略，備份作業自動化，實現數據的在線備份和離線歸檔。在備份設備中使用高速的備份介質，減少日常備份/恢復作業對系統可用性及性能的影響，實現快速的備份/恢復機制。系統設計原則

1、存儲系統的設計原則

? 提高存儲空間利用率，節省總體數據存儲成本，有效提高投入產出比。

? 數據整合，進行統一的管理與應用，降低管理員的工作量以及人力開支成本。? 磁盤陣列的讀寫速度與穩定性要高。? 支持靈活安全的在線擴容。

? 采用多種RAID模式使設備更加可靠，保證有磁盤損壞時不影響數據。

? 專用的外置存儲設備支持控制器、電源、鋰電池、風扇等關鍵部件的熱插拔，故障部件可以在線更換； ? 可以實現分級存儲功能；

備份系統的設計原則

? 可以采用專用的備份網絡，避免業務系統網絡和備份網絡的互相干擾。

? 針對特別的應用，可以提供零窗口和LAN-Free的備份方式。? 支持介質復制的斷點續傳，減少網絡帶寬，提高網絡帶寬的利用率。

? 數據的備份采用D2D2T策略，通過在線的磁盤陣列，近線的虛擬磁帶庫，離線的物理磁帶庫，共同完成信息生命周期的數據安全基礎架構。

集中存儲系統具體描述

對于醫院的數據中心，本方案將構建一套FC SAN的存儲架構，將用戶的關鍵應用系統數據（如： HIS服務器，PACS服務器）集中存儲在一臺光纖磁盤陣列（作為一級存儲設備）中，該磁盤陣列配置雙機頭，確保了存儲設備的高可靠性。磁盤陣列可以實現FC磁盤和SATA磁盤的混插，數據可以保存在高穩定性的FC磁盤中，將來可以考慮上SATA磁盤，實現數據在一套設備內的分級存儲。

在主機與存儲的連接鏈路上，接入SAN的所有主機，可以配置2塊HBA光纖適配卡，同時連接兩臺光纖交換機，確保任何一條光纖鏈路中斷均不會影響用戶的正常業務使用，完全消除了單點故障。統一的集中化存儲

在本次方案中，根據我院目前的存儲空間規劃，以及我院未來三至五年內的需求，給我院配置3TB的存儲可用空間用于SAN的數據集中存儲，配置質量和性能都比較好的FC硬盤來存放數據。同時，為防止磁盤陣列自身出現嚴重的物理故障導致數據丟失，還可以另外選配兩臺磁盤陣列，兩臺磁盤陣列之間通過卷復制功能來實現兩臺存儲設備之間的數據同步。

對于以后需要增加的其他應用服務器，將來可以通過增加光纖HBA卡的方式，接入FC SAN。SAN存儲架構

SAN存儲架構具備良好的擴容性，未來可以方便地升級與維護。當信息系統需要擴建時，只要把新的設備，接入到SAN架構中，便可以使用集中存儲提供資源，所以，SAN架構，可以作為一個基礎的設施來建設，它可以充分地保護投入的成本，為日后系統的擴容，升級打下了良好的基礎。SAN存儲架構的特性：

1.可實現大容量存儲設備數據的共享。

2.可實現高速計算機與高速存儲設備的高速互聯。3.可實現靈活的存儲設備配置要求。4.可兼容以前的存儲設備。5.提高了數據的可靠性和安全性。6.避免了數據的“信息孤島”效應。數據備份與恢復的跨平臺性和可靠性

現在的備份軟件已經比較成熟，如CommVault,Symantec,NetStor Backup Express等等

數據備份恢復軟件的跨平臺性表現在：

? 能把備份UNIX文件恢復到不同版本的UNIX系統；

? 能把UNIX的備份文件恢復到Windows、FreeBSD、HP-UX、IRIX、Linux、Solaris、Tru64操作系統上。

? 能把備份文件恢復到不同版本的Windows系統，即在NT、2000、XP、2003之間實現跨版本恢復。

? 能把Windows的備份文件恢復到SOLARIS、FreeBSD、HP-UX、IRIX、Linux、Solaris、Tru64異構平臺的操作系統上。數據備份恢復軟件的可靠性表現在：

?? 能實現備份、恢復及備份數據轉存的中斷再繼續（斷點續傳功能）。? 能對Oracle進行斷點續傳備份，確保備份成功率。

? 支持并發數據流，加速備份過程，充分利用多磁帶驅動器的磁帶庫設備。

? 能對增量備份、差量備份實現智能的、快速的“一次過”恢復，確保一次性讀入要恢復數據的最新版本，極大提高恢復效率

本方案采用現在最先進的FC-SAN架構，實現了高速計算機與高速存儲設備的高速互聯，實現了信息的集中存儲，避免了信息孤島的形成，同時，為以后醫院信息化的建設打下了基礎。

完整的備份系統，可以保證數據的最大安全性，從數據的產生，數據的備份，到長久數據的歸檔，D2D分級存儲架構完成了一個信息的生命周期。同時，數據實現自動備份，減少人工參與，降低醫院的管理成本，有效地保障了醫院數據的安全

五、技術、經濟效益、市場風險分析

在現代醫院越來越依賴計算機來對醫院的業務的開展和管理的今天，數據的安全無疑是重中之重，而數據的安全又是建立在存儲系統的基礎上，所以，一個架構完整、合理、科學的存儲系統，是實現現代醫院信息化過程中必須走的重要的一步。

高效的容災備份系統和主-備服務器的快速切換模式可應用于所有類型數據備份系統，有效提高數據服務器的工作效率，大大降低數據信息丟失的風險成本。全自動化模式提高了備份系統的穩定性，同時降低了醫院管理成本。

六、申請單位簡況

榆林市第三醫院是市委、市政府批準成立的一所綜合性、非營利性公立醫院。醫院位于東沙城區金陽小區旁邊，環境優美、交通便利、設備先進、功能齊全、技術力量雄厚、服務熱情周到，是充分體現“以人為本”的綜合醫療服務機構。

醫院現開放床位302張，設置有綜合內科、綜合外科、骨科、婦產科、兒科、手術麻醉科、急診科、康復理療科、中醫科、皮膚科、眼科、口腔科、耳鼻喉科、感染科等14個臨床科室；影像科、檢驗輸血科、藥械科、功能科（B超室）、病理科、心電圖室、腦電圖室、消毒供應室、內鏡室、門診部等10個醫技科室。現有干部職工280人，其中專業技術人員243人，特聘專家13人，副高以上26人，中級35人，本科78人；行政及后勤管理人員37人。

擁有全進口美國GE16排螺旋CT機、美國GE DR、美國GE數字胃腸機、腹腔鏡、富士激光相機、西門子全自動生化分析儀、血液分析儀、飛利浦高端彩色B超機、德國進口高端呼吸機、麻醉機等大型醫療設備。

醫院始終堅持貫徹執行黨的衛生方針、政策，堅持“看病明白、檢查準確、合理用藥、花錢清楚、一切為了患者”的服務理念，著力打造特色服務品牌，不斷提升診療技術水平。我們以精湛的技術、創新的理念、全新的面貌，竭誠為患者提供安全、高效、便捷、嚴謹的醫療服務，今天的榆林三院將以新起點、高標準、跨越式的發展創造輝煌的業績，為人類健康事業的發展而努力奮斗！該項目由榆林市第三醫院信息科負責實施。

七、必要的支撐條件、組織措施及實施步驟

暫定項目預計于2015年11月至2016年2月之間完成項目所需的網絡環境與硬件設備及項目實施場地的建設。于2016年2月至2016年5月之間完成項目的關鍵技術，達到項目技術指標；同時完成項目實施內容記錄與所有相關技術問題的擴展總結

八、計劃實施進展、預算及來源渠道

項目總投資19萬，擬申請政府補助10萬，單位自籌9萬。其中硬件采購17萬，項目實施費用2萬

詳細配置參數列表

序號 采購內容

HBA卡

技術規格或性數量

能指標 ★HBA卡：每臺配4個 套HBA卡：2個，光纖線3M LC-LC2條 ★售后服務：提供原廠3年保修服務,中標方須在簽訂合同前提供原廠商服務承

報價

12000

諾函 備份服務器(X3650M4)

CPU：E5-2603 1臺 @1.80GHZ

1.80GHZ(2處理器）

內存：8GB 網卡：Intel I350 Gigabit Network

Connection(4塊)

硬盤：2TB SATA（3塊）★HBA卡：每臺配套HBA卡：2個，光纖線3M LC-LC2條 可管理和維護性：光通路診斷，集成IMM(可選的Virtual Media Key支持Remote Presence)系統

支持的操作系統：MS Windows Server 2008、Red Hat Linux 和 SUSE

Linux、Vmware ESX Server、標配windows2008 服務

★售后服務：提供原廠3年保修服務,中標方須在簽訂合同前提供原廠商服務承諾函

35000 3 磁盤陣列(DS3500)

★品牌：與服務1臺 器同品牌產品 控制器：配雙控制器，4個6Gbps SAS主機接口，Cache具備斷電保持數據完整功能。

支持SAN：支持SAN光纖通道交換機、支持1GBps/2GBps/4GBps

★主機接口：≥8個，8Gbps FC 主機端口

★數據Cache：每個控制器≥1G ★存儲容量：本次硬盤配置數量≥10塊，300G以上 3.5" SAS 15k rpm 最大驅動器數量：≥96個 圖形化管理軟件：配置圖形化管理軟件 多通路容錯及動態負載均衡功能：支持 安全訪問控制：防止LUN被未授權主機訪問。支持Cache分區技術：支持 快照：支持 支持的操作系統：Microsoft Windows 2003, Sun Solaris, IBM AIX, Linux, Novell Netware。

99000

高可用性：完全的硬件冗余：處理器、電源、風扇、適配卡等都提供冗余，并保證在某硬件出現問題，能夠進行自動切換，不出現單點故障。4 5 備份軟件（Symantec Backup Exec Leo 11D Win）系統集成 要求 ★服務要求：提供3年7×24小時原廠上門保修維護

Back Exec沿襲最初在賽門鐵克Veritas NetBackup中使

用的針對虛擬環境的獲獎技術，通過單一管理控制臺為VMware Infrastructure、Microsoft Windows Server 2008 Hyper-V以及傳統的物理系統提供全面的數據保護，同時降低成本，并提高多重虛擬和物理系統的管理。

工作內容

1、說明:數據文

件大小在20G左右進行平滑遷移。★

2、進行數據模擬遷移（根據設計的數據遷移方案，建立一個模擬的數據遷移環境，它既能仿真實際環境又不影響實際數據，然

套30000

硬件總價*10% 1 后在數據模擬遷移環境中測試數據遷移的效果。數據模擬遷移前也應按備份策略備份模擬數據，以便數據遷移后能按恢復策略進行恢復測試）

3、測試數據模擬遷移（根據設計的數據遷移測試方案測試數據模擬遷移，也就是檢查數據模擬遷移后數據和應用軟件是否正常，主要包括：數據一致性測試、應用軟件執行功能測試、性能測試、數據備份和恢復測試等）

4、準備實施數據遷移（數據模擬遷移測試成功后，在正式實施數據遷移前還需要做好以下幾個方面工作：進行完全數據備份、確定數據遷移方案、安裝和配置軟硬件、制定應急方案等）

5、正式實施數據遷移（按照確定的數據遷移方案，正式實施數據遷移）測試數據遷移效果（按照數據遷移測試方案測試數據遷移效果，并對數據遷移后的數據庫參數和性能進行調整，使之滿足數據遷移后實際應用系統的需要）

6、移植系統應用軟件(將實際應用系統的應用軟件移植到數據遷移后的數據庫系統上，并使之正常運行)

7、正式運行應用系統(在正式實施數據遷移成功并且數據庫參數和性能達到要求后，就可以正式運行應用系統，并投入實際使用)

8、數據庫升級到Windows+Oracle 11g。

9、數據庫遷移時間控制在2～3小時內，不能超過4小時，須提供詳細的升級、遷移方案。

10、數據庫遷移時能繼續支持醫院業務的正常運行，包括門診業務(如門急診收費、門診藥房、門診診間、皮試系統等),及重要的住院業務(如住院收費、醫囑等)，須提供詳細方案來滿足遷移要求。

第四篇：容災備份解決方案

2010-8-11 容災備份系統簡介

一、項目背景

隨著計算機技術的快速發展，每個企業都在大量的使用計算機處理自己的核心數據，這些數據往往是企業生產經營必不可少的部分。依賴這些數據的計算機系統的停機往往會造成企業生產經營活動的停頓，給企業造成巨大的損失。所以，可以說，這些數據是企業的生命核心。企業的IT管理員為了保證生產經營活動的持續運行，不斷的加強對系統和數據的保護，如使用基于雙機的高可用技術，磁盤陣列系統的RAID技術等。然而，人們依然無法回避由于磁盤故障，人為失誤，應用程序的邏輯錯誤，自然災害等原因帶來的系統停機或者數據丟失。所以，數據備份作為數據保護的最后一道屏障，必不可少。

二、功能介紹

實時保護：連續捕獲、實時備份數據變化，全過程保護數據安全。實現真正的持續性數據保護（CDP），無需設置任何備份時間點，居國內外同類產品領先地位。

完善備份：同一軟件可實現“數據庫雙機熱備＋接管”、“本地實時災備”、“異地實時災備”，全方位保證數據庫安全。

任意回退：可按任意操作步數或時間點進行數據回退。主數據庫遭到破壞時，備份數據庫可將主數據庫回退到損壞前最后時刻的狀態，且能保證事件的完整性。快速恢復：主數據庫或表損壞，從站自動檢測，提示回退的步數。恢復1個G數據庫在3－5分鐘。

增量備份：只備份變化部分，在保障備份數據安全的同時減少備份的工作量。

錯峰機制： 在系統負荷極大時暫停備份以免系統癱瘓，當系統負荷下降時備份暫停期間的數據，并重新開始實時備份。

低耗資源：對主數據庫壓力小，系統采用消息機制，只有災數據庫發生變化時才觸發，只傳數據庫的變化部分，不同于文件拷貝，和數據表的輪詢。

操作簡單：自主開發設計，著重考慮國內用戶使用習慣，安裝、設置非常簡單。

維護方便：啟動或連接中斷后重連時，自動校驗主從站數據，保證數據準確。

加密傳輸：底層通訊采用自主研發的通訊平臺，所有數據都是用加密數據包進行數據交換，充分保證數據安全。

高性價比：在各項性能領先的同時，價格遠遠優于國外軟件。當選擇不接管的熱容災備份方式時，從站可采用低檔Server或高穩定性的PC（有足夠的存儲空間即 2

可），從而實現極低的總體成本。

通用性好：不對數據庫中的應用做任何修改。與數據庫中表的結構無關，且無任何限制。對數據庫備份完整：如TABLES（表）、DIAGRAMS（關系圖）、VIEWS（視圖）、USERS（用戶）、ROLES、RULES等。

三、解決方案優點

能夠實現雙數據庫的實時同步，能夠保證雙份數據庫的實時一致性，如果主生產數據庫失敗，備數據庫庫服務器隨時可啟用為主數據庫服務器。不再需要介質恢復的過程。

多節點存儲冗余體系

熱備方案要求最少有雙份數據庫，不但心生產數據庫崩潰，磁盤硬件崩潰，而造成數據庫不可用問題．多份數據源才是真正的冗余體系，真正消除了數據庫系統管理人員為存儲單點故障的后顧之憂!不存在物理介質恢復時間問題

因為雙數據庫的實時同步，保證雙份數據庫的一致性，如果主生產數據庫失敗，備數據庫庫服務器隨時可啟用為主數據庫服務器．不存在介質恢復時間．這與雙機熱備比較，完全消除掉備份恢復這一個過程。

同步時間完全實時

主數據庫與從數據庫可以做到實時同步，消除了備份軟件中的間隔備份丟失數問題．同時提供了完全不丟失數據模式和丟失秒內業務數據校正方式。

解決了數據誤刪除恢復問題

與HA,CDP軟件比較，當數據庫管理人員遇到意外誤刪除求助，熱備系統可以提供事務級別的按步數或者時間點的回退動作，確定記錄，恢復記錄.不需要像傳統備份軟件為了一個記錄而恢復整個數據庫。

數據庫異地容災問題

完全支持異地數據同步，支持斷點續傳，數據一致性校驗。

四、解決方案

（一）1、備份方案

（一）示意圖：容災標準版（一主一從）

備份方案：

說明：

1：在1號Server系統中安裝，設置成主站。2：在2號Server上安裝，設置成從站

3：正常運行后，2號Server能夠實時備份1號Serve中的數據庫的數據 4：在1號Server宕機的情況下，2號Serve能接管主服務器的IP和機器名，對外提供所有的服務，保證業務不間斷

5：當1號Server修復后，能快速將2號Server上數據恢復到1號Server中。

能實現的效果及主要功能：

1)將主服務器上的數據實時智能的備份到從站備份服務器里

2)如果數據庫遭到病毒破壞或者誤刪除可用數據回退進行解決；回復的任意時間點的數據

3）主站宕機或者磁盤柜損壞，備份服務器可接管主站服務器對外服務，保證客戶端的正常運行

2、備份方案

（二）示意圖：容災（一主兩從）版本

S2備份服務器S1主數據庫服務器 終端 S3備份服務器辦公樓 XX樓

說明：

1)2)3)4)主站服務器（S1）安裝標準版軟件設置成主站；

從站備份服務器（S2）安裝標準版軟件設置成從站1，作為備份服務器1； 從站備份服務器（S3）安裝M標準版軟件設置成從站2，作為備份服務器2； 正常運行后，從S1能夠同時實時備份主站或磁盤柜中的數據庫數據到S2、S3；

能實現的效果及主要功能： 5)在S1或磁盤柜損壞的情況下，S2能接管S1對外提供服務，保證客戶端的正常運行，當S2亦出現意外事故時，S3能接管S2對外提供服務，保證客戶端的正常運行；

6)當主機房損壞設備完全修復后，能快速將S2或者S3上數據恢復到S1存儲中。3)將數據中心的SQL數據庫中的數據實時的備份到從站服務器中； 4)如果數據庫遭到病毒破壞或者誤刪除可用數據回退進行解決； 5)如果主站宕機或者磁盤柜損壞，備份服務器可接管主站服務器對外服務，保證客戶端的正常運行。

3.方案

（三）方案示意圖：集群版（兩主一叢）

針對雙機磁盤柜的異地容災：

主數據服務器雙機環境 磁盤柜 終端 雙機 集群 備份服務器１號２號 實時備份 數據回退 接管 異地容災 ３號server

說明：

1、在1、2號server組成的集群系統中安裝 FOR CLUSTER版設置成主站；

2、在3號server上安裝 FOR CLUSTER版設置成從站；

3、正常運行后，3號server能夠實時備份集群磁盤柜中的數據庫數據；

4、在集群中的1、2號機器同時宕機或磁盤柜損壞的情況下，3號server能接管集群對外提供服務，保證客戶端的正常運行；

5、當主數據服務器被損壞設備修復后，能快速將3號server上數據恢復到集群存儲中。

能實現的效果及主要功能：

1）避免了雙機集群的磁盤柜的單點故障，有雙份數據安全。2）數據庫遭到病毒破壞或者誤刪除可用數據回退進行解決；

3）主站同時或者磁盤柜損壞，備份服務器可接管主站服務器對外服務，保證客戶端的正常運行。

4.方案

（四）方案示意圖：集中備份（多對一）

數據服務器 業務數據 辦公server備份中心 辦公數據 業務server１號２號財務server實時熱備接管回退管理server異地備份集中備份ＸＸ server 管理數據 ３號Ｘ號 XX數據

說明：

1、在各個主數據服務器系統中安裝，設置成主站；

2、在備份中心的備份服務器上安裝，設置成從站；

3、正常運行后，備份中心能實時備份數據服務器的數據庫數據；

4.任一主服務器的數據丟失后，都可以從備份服務器迅速的給主服務器恢復數據。

能實現的效果及主要功能：

1.可以把各個業務服務器數據庫的數據實時智能的備份到數據中心的服務器里，當任何一個主業務服務器的數據丟失時，都可以從數據中心的服務器里進行快速的恢復。

5.方案

（五）方案示意圖：集中備份（本地做一對一，異地做多對一）

說明：

1：在各主服務器SERVER 1-N中安裝設置成主站，在SERVER1’ –SERVERN’中安裝設置從站，主從站通過數據庫保鏢進行實時備份，當本SERVER 1-N出現問題后，對應的SERVER1’ –SERVERN’可以進行接管或恢復。

2：SERVER作為集中備份服務器，將SERVER 1-N中的數據實時集中備份到SERVER內，即使本地數據丟失，也可以從數據中心取回。

能實現的效果及主要功能：

1.可以實現本地的數據實時備份和接管，當主服務器出現宕機時，可以迅速的用備份服務器接管主機提供對外的服務，保證業務不間斷。

2.當主服務器本地出現意外災難，數據全部丟失后，可以通過遠程的中心服務器恢復數據，保證了數據的安全。

五、容災容災備份系統能實現的效果和功能

1．能實現對主服務器上的數據庫里的數據進行實時智能的備份，保證了數據的安全，一旦出現數據丟失或破壞，可以迅速的從備份機上把數據恢復回來。第一次做個全備份，把數據全部備份到備份機上，以后每次只做增量備份，把變化的數據做實時的備份，節省了備份空間，提高了備份效率。在備份時對服務器的性能沒有影響。

2．當主服務器出現意外宕機時，備份機可以立刻接管主服務器的IP，提供對外的所有服務，保證了核心業務連續性，可以提供365天7*24小時的業務不間斷的保護。

3．整個備份系統具有高容災性和可擴展性，以后隨著數據量的增加也可以增加磁盤陣列等。

4．可以做到異地備份，真正的做到了有備無患。

第五篇：數據中心容災備份方案

數據保護系統

醫院備份、容災及歸檔數據容災

解決方案

1、前言

在醫院信息化建設中，HIS、PACS、RIS、LIS 等臨床信息系統得到廣泛應用。醫院信息化 HIS、LIS 和 PACS 等系統是目前各個醫院的核心業務系統，承擔了病人診療信息、行政管理信息、檢驗信息的錄入、查詢及監控等工作，任何的系統停機或數據丟失輕則降低患者的滿意度、醫院的信譽丟失，重則引起醫患糾紛、法律問題或社會問題。為了保證各業務系統的高可用性，必須針對核心系統建立數據安全保護，做到“不停、不丟、可追查”，以確保核心業務系統得到全面保護。

隨著電子病歷新規在 4 月 1 日的正式施行，《電子病歷應用管理規范（試行）》要求電子病歷的書寫、存儲、使用和封存等均需按相關規定進行，根據規范，門(急)診電子病歷由醫療機構保管的，保存時間自患者最后一次就診之日起不少于 15 年；住院電子病歷保存時間自患者最后一次出院之日起不少于 30 年。

2、醫院備份、容災及歸檔解決方案

針對醫療衛生行業的特點和醫院信息化建設中的主要應用，包括：HIS、PACS、RIS、LIS 等，本公司推出基于數據保護系統的多種解決方案，以達到對醫院信息化系統提供全面的保護以及核心應用系統的異地備份容災

2.1 數據備份解決方案

針對于醫院的 HIS、PACS、LIS 等服務器進行數據備份時，數據保護系統的備份架構采用三層構架。

備份軟件主控層（內置一體機）：負責管理制定全域內的備份策略和跟蹤客戶端的備份，能夠管理磁盤空間和磁帶庫庫及光盤庫，實現多個客戶端的數據備份。備份軟件主服務器是備份域內集中管理的核心。

客戶端層（數據庫和操作系統客戶端）：其他應用服務器和數據庫服務器安裝備份軟件 標準客戶端,通過這個客戶端完成每臺服務器的 LAN 或 LAN-FREE 備份工作。另外，為包含數據庫的客戶端安裝數據庫代理程序，從而保證數據庫的在線熱備份。備份介質層（內置虛擬帶庫）：主流備份介質有備份存儲或虛擬帶庫等磁盤介質、物理磁帶庫等，一般建議將備份存儲或虛擬帶庫等磁盤介質作為一級備份介質，用于近期的備份數據存放，將物理磁帶庫或者光盤庫作為二級備份介質，用于長期的備份數據存放。

2.2 應用級容災解決方案

實時保護，可實現對醫院信息系統中核心業務系統的持續數據保護。在核心業務系統應用數據寫入被保護服務器自身存儲的同時，寫入存儲設備中，顆粒度到秒級，最佳情況下可實現零數據丟失，通過鏡像功能保證連接的磁盤陣列中的數據與被保護的數據完全一致。同時，利用截獲每個寫I/O 功能并進行記錄，并且可基于時間點的快照進行回滾，此功能能夠在被保護服務器發生邏輯錯誤時，快速有效地進行每 I/O 節點或快照點的掛載，避免邏輯錯誤造成的數據損壞。當存儲系統宕機等災難發生時，采用快速掛載功能，可以最快在分鐘級別內迅速恢復前端應用或數據庫服數據功能，保證業務的連續性。

分流器：截取主機寫操作(塊級別), 主機每次對被保護磁盤的寫操作均被鏡像寫入到鏡像數據寫入過程在主機的主存儲讀寫路徑之外。

數據卷：保存主機分流器寫入的所有數據。

記錄卷和一致性代理：保存主機分流器寫入的 I/O 記錄根據應用特點 , 通過技術中的一致性代理實現對 ORACLE、MS SQL 等數據庫在保存應用數據一致性快照使數據能夠快速恢復到任意 I/O 記錄。2.3數據系統長期歸檔解決方案

可通過高級備份功能，把電子病歷、PACS 影像等數據備份到內置空間后，歸檔一份到光存儲中，通過光存儲的可長期保留特性，實現數據的長期保留（最長可到 100 年以上），滿足法規要求。

2.4數據系統容災解決方案

數據保護系統內置災備功能，可實現數據及應用級別的容災，可支持一對一，多對一等多種拓樸架構，系統可互為源端及目標端，完成異地備份、恢復功能。

1）數據級容災：

備份數據保存在設備中，各備份點的數據可獨立管理，可實現異機恢復，提高數據的安全性。

2）應用級容災：

數據保護系統的 CDP 功能把數據持續保護在本地設備時，并可把本地CDP 數據復制一份到異地，CDP 的卷可以直接在異地直接掛載使用，結合虛擬機功能實現應用級容災。

3、方案優勢

數據保護系統提供的數據備份、CDP 及歸檔功能一體解決方案，滿足醫院信息系統的數據安全、應用級容災及法規要求（電子病歷數據長期保存的要求）的業務需求，解決方案優勢如下：

1）軟硬一體化結構，數據保護系統是多功能于一體的數據保護設備。包含了備份、CDP、存儲（FC、ISCSI 及 NAS）及數據歸檔等多種功能，更加經濟實用。并且部署簡單，插入網線后進行簡單配置后即可開始使用。

2）支持 FC、千兆及萬兆網絡等鏈路，靈活部署。

3）在同一臺設備支持部署定時備份、CDP 功能，針對不同應用級別提供不同的保護方式。

4）具備遠程復制功能，兩臺以上的設備可以實現遠程復制，任意兩臺設備都可以作為發送端與接收端進行相互的遠程復制，實現異地容災，使數據更加安全。

5）具有高級備份功能，能實現 PACS 等大量的非結構化數據的不打包備份，可實現 100TB 級別以上的非結構化數據的光盤庫出庫歸檔，同時采用高級備份時光盤庫恢復可通過備份系統和光盤庫直接恢復等多種方式恢復方式，更加安全可靠。

6）運維簡單，本方案采用一體化部署，提供統一的運維界面，用戶操作簡單，備份歸檔自動化完成。同時也提供完善的系統報告，方便客戶使用。