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 - 業務連續性而不僅僅是 Disaster Recovery - "災難"恢復。因為過去的"災難"恢復計劃並沒有強調全域性性及對整個市場的影響，而如何維持業務的連續運作將成為企業運營風險評估中至關重要的一環。事實證明，只有對資料儲存備份制定完備、持續且可執行的容災計劃，特別是業務連續計劃，才能為人們提供萬無一失的資料安全保護。

嚴格的說，容災計劃包括一系列應急計劃，如業務持續計劃(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關注在中斷期間和之後維持機構的業務功能。業務功能的一個可能的例子是工資的支付處理蚩突У男畔⒋懟CP可以專門為某個特定的業務處理編寫也可以涉及到所有關鍵的業務處理。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資料丟失率，被認為是災難恢復的最高級別，在本地和遠端的所有資料被更新的同時，利用了雙重線上儲存和完全的網路切換能力，當發生災難時芄惶峁┛繒鏡愣涸仄膠夂妥遠低徹收杴謝還δ堋?/p>

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.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層災難恢復方案可以保證最高一級