區別性災備，守好信息安全的最後一道防線

摘要：災備其實是一個體系，應該靈活利用各種災備手段，對不同的數據和應用進行區別性的災備。本文由英方股份CTO周華在鈦媒體在線課「鈦坦白」第50期分享整理而成。

一、災備是什麼？

災備，是指災難備援。作為IT產品，災備跟生活中的保險類似，保險不保安全，只是在事故發生後進行的一種理賠，而災備是在事故發生后的補救措施，即當事故發生之後需要保護客戶的數據不丟，業務不停。

在網路安全領域，防火牆和殺毒軟體是在一線的，但是當這一道防線沒有攔住相關潛在的威脅，災備就是信息安全的最後一道防線，是救命稻草。

災備不僅僅是數據級簡單的一個備份，還有業務連續性相關的一些需求。良好的災備策略不僅能減少企業的災備應對時間，還能大規模降低企業因為業務終端而導致的損失，並提升客戶的使用體驗。

災備分三個等級：

第一個是數據級災備。數據級有很多種方式，比如定時備份，每天晚上或者每隔一段時間做一次備份。另外一種比較高級的容災方式是持續的數據複製和實時同步。

第二個是應用級災備。應用級是在數據級的基礎之上，能夠確保應用相關進程服務的連續性，包括本地和異地的應用級容災，確保當生產端出現故障時，備端的應用能夠快速切換接管。

第三個是業務級災備。如果說數據級災備、應用級災備都是在IT系統的範疇之內，業務級災備則是在以上兩個等級的災備基礎上，還需考慮到IT系統之外的業務因素，包括備用辦公場所、辦公人員等，而且業務級災備通常對支持業務的IT系統會有更高的要求。

這三個層次之間的關係是逐級而上的。最基礎的是數據級，其次是應用級，最高級是業務級。一般情況下，企業會進行數據級和應用級的建設。在災備建設時，每個企業因為生產環境與喜好不同，使得災備的交付方式也不一樣。英方根據多年的災備交付經驗，在業內率先提出了「軟體+硬體+DRaaS」的全生態交付模式，以適應不同企業對災備建設的需求。

二、傳統災備存在的問題

災備所需要應對的範疇包括IT系統問題、計算機網路安全技術問題、信息安全管理問題、災害類問題等，當這些事情發生時，我們需要有保護數據和整個系統完整性的措施。

比如說勒索病毒，我的一位同事中招了，他的iphone還有相關蘋果的設備都被鎖定。還有一個英方的企業客戶，相關的重要數據也被勒索病毒給加密了，最終他付了錢，但付了錢也沒用，數據沒有被恢復出來，最後全部要重新去整理。這些潛在威脅就像緊箍咒一樣，你不知道什麼時候會發生。一旦發生，我們該怎麼樣去保證數據的安全呢？

目前企業也採取了大量的安全措施，比如在前端為了防止網路的攻擊，可以用相關的殺毒軟體，或者對關鍵數據進行定時備份，甚至更高級別的災備，比如兩地三中心。在金融行業如證券和銀行，要求高，所以災備建設比較靠前，兩地三中心是比較普遍的要求，甚至規定物理生產中心與災備中心之間的物理距離不能低於多少公里，異地的災備中心物理距離不能低於多少公里，相關的數據要在幾分鐘之內能夠恢復出來。這不得不說災備行業裡面經常提到一句話——不要將所有的雞蛋放在同一個籃子里。

而現在，企業對於關鍵數據的重視程度也越來越高，會把數據放在不同地方。比如說上雲，企業可能會同時將數據放在阿里雲和騰訊雲上，然後利用英方的容災方案做數據的實時保護和容災接管，實現本地到雲端、雲端到雲端的備份、恢復和高可用。

針對信息安全的災備建設，市場很早就有相應的災備手段，比如定時備份，但是隨著數據量的增加，問題也逐漸暴露，比如定時備份有時間窗口，數據從開始備份到備份完成需要一段時間。隨著業務的發展，數據量會越來越大，那麼備份的時間窗口會越來越長，到某一個程度的時候，當天產生的數據可能當天也無法備份完成。

很多人可能沒法理解，我當天產生的數據怎麼會沒法備份完呢？舉個例子，在金融行業，有些部門實際工作時間是7×24小時不間斷運行的，不會留有足夠的時間給你備份。另外，多系統的集成和運轉，業務移動化和雲端化也給企業的災備建設帶來考驗，這些不斷出現的新場景，顯然傳統的定時備份、雙機熱備等難以應對。而大型企業一旦出現業務中斷，可能受到的影響會很大，甚至產生很不好的輿論場。比如某個網站因為宕機而導致業務停止22個小時，又比如說一鋤頭把光纖挖斷了，所有終端的業務都受到影響無法使用等。這些都表明，數據複製的實時性與業務連續性成為企業的剛需。

三、新的災備方案

上面說傳統災備在新的場景需求下出現了瓶頸，但並不等於傳統災備方式會消失。我們說災備其實是一個體系，在英方的客戶群里，很多用戶都採用了綜合性的災備方案，即傳統災備+新的災備方案，就是靈活利用各種災備手段，對不同的數據和應用進行區別性的災備，比如傳統的災備可以定時備份一些日常的普通數據，關鍵的對實時性要求高的業務，可以用新的災備方案。「新」在哪裡呢，下面是我們提供的三種新解決方案：

·實時性同步

實時性災備與傳統災備的區別是，英方通過位元組級技術監控，把原端產生的數據源源不斷地發送到備端。一般情況下，英方位元組級複製技術可以實現毫秒級的數據傳輸，丟失的數據也是毫秒級的。

舉一個應用場景，買股票。買股票第一要看行情，包括漲跌的數據、股票價格等，而這些數據變化是非常快的，1秒鐘可能會變化多次。這些是表面的變化，實際上背後是數據的同備，這個數據同步技術用的是英方的i2Distributior，現在很多的大的券商，包括海通證券、東方證券、中信證券等這塊相關的行情分發就是用i2Distributior進行數據的同步。

行情分發是怎麼回事呢，過程可以簡單描述一下：首先系統會將從上交所、深交所產生的行情源下放到證券公司；其次證券公司會再同步到所有的營業網點、大戶室（部分券商已經不把這個系統放在本地機房，而是放在雲端）。這個過程需要系統把搜下來的這些數據快速的同步到各大相關的終端站點，或者是雲端的雲主機上面去。

這裡面其實就兩個要求：第一、毫秒級到達所有需要到達的點；第二、佔用的網路帶寬越少越好。在用戶現場的PK中，用戶擺了兩台伺服器，一台用一種行業比較牛的技術去搜行情源，另外就是用英方的i2Distributior，現場看誰搜出來的速度更快，結果是英方的更快。

·業務連續性

業務連續性是相對數據實時同步要求更高的一種災備模式，它要求當故障發生時，業務系統不要停。

這涉及到應用級相關的接管，不僅僅是應用還有數據，必須是某個狀態兩端的一致性，整個備端相關的平台才能起來（兩端既要支持物理機、虛機和資料庫，或者是Web應用、ERP系統各類應用相關的一些兼容性）。

英方i2Availability能夠做到秒級接管，舉一個例子，去年有家金融客戶的FLASH卡壞掉，業務系統被切換到備端，但是直到下班，相關的人員才發現生產端已經宕掉。英方的技術員趕過去調出相關的日誌分析，原來是FLASH卡壞掉出現物理故障，監控程序上傳后馬上切換到備端，阻止了這次事故的發生。優秀的業務連續性方案，能夠做到發生切換時用戶端無感。

·雲災備

這兩年，上雲的客戶越來越多。因此災備架構也由傳統的IT架構升級到雲IT架構，雲災備目前不僅僅指災備，還包括業務的上雲遷移、雲備份和恢復、雲高可用。

雲遷移會是一個比較重要的應用場景，比如浙江的一個三甲醫院，它把相關的醫療影像數據同步到阿里雲的OSS面向對象存儲裡面去。另外還有一些國企，比如中央的某部委項目，採用混合雲的方式將一部分數據放在本地，另一部分存量或歸檔數據放在雲端。

雲端對企業來說可以緩解初期一大筆資金的投入，資源可以動態的分配，前期可以節省很多的相關費用。但是在完全雲端化之前，企業要面對這樣的場景：

i2Move：生產不間斷，整體熱遷移

一是部分業務上雲，本地的系統和配置要繼續使用，那麼就需要在本地和雲端之間進行數據的實時同步。英方i2Move能夠把用戶的大規模的業務系統在本地直接一鍵式遷移到雲端。比如我們將電科院的三百多台伺服器不停機一鍵式遷移到私有雲上，還有從企業內部遷移到阿里雲、騰訊雲、華為雲等公有雲上，保障遷移過程數據不丟，業務不停。

i2CDP：可恢復至任意時間點

二是本地繼續作為傳統的生產中心，雲端定位為非敏感數據的備份及部分業務的容災，比如對外可查詢的數據、網站等，那麼這就需要在本地與雲端之間做CDP數據恢復和業務高可用容災。