【51CTO.com 原創】這次開場我和大家來個brainstorm吧。當提到存儲和備份的時候，大家會想到哪些詞語呢?

“高可用，高性能、彈性擴展、可按需提供服務， 保障7*24小時的業務連續性，確保數據的一致性、安全性……”

這說明大家已經有了數據保護方面的意識和要求。這使我想到了在大學計算機課程中曾學到的諾蘭模型，據個人觀察，目前國內大多數企業對于存儲備份已經處于了從簡單的技術集成階段向合理化管理和使用階段邁進的演進中。即“組織使用數據庫和遠程通信技術，整合現有的信息系統”的階段，慢慢過渡到“組織開始全面考察和評估信息系統建設的各種成本和效益，全面分析和解決信息系統投資中各個領域的平衡與協調問題”(此處遠方傳來一聲“快閃開，廉哥又要開始裝高逼格!”)。說通俗點，當前大多企業要處理的不是有沒有備份的問題，而是備份是否得當、有效并與時俱進的問題。

所以我這次來談談我在這方面的設計和治理的心得與經驗吧。這樣接地氣的方式容易引起小伙伴們的共鳴。

[[171865]]

備份技術

先嘮叨、復習一下統一存儲的基本概念吧。雖然大家可能都已經明白，而且根據本企業的實際情況已經在內部的傳統系統中部署了FC SAN、IP SAN(iSCSI)和NAS三種存儲架構中的任意一種。其中FC SAN、IP SAN的傳輸方式是數據塊，而NAS則用文件。而從傳輸介質來看，FC用的是光纖，而IP SAN和NAS則用的是雙絞線。在實際場景中，對需要高性能、高帶寬的服務器，多數采用FC SAN架構;對普通文件服務器采用則IP SAN架構;而對于需要進行文件共享的應用也可以采用NAS架構。

然而，大家是否意識到，很多情況下，是為了配合某些新上馬的應用系統，我們時常需要集成和采取一套相應的軟硬件存儲、備份措施，而這在某種意義上導致了整個大系統在宏觀上成為了各種數據保護和備份容災產品的“自治領”。此現象在那些有多個ROBO(遠程辦公室分支辦公室)的企業里尤為突出。而其結果就是：由于備份災備產品種類多，在產品選型和測試上，需要花費比較多的時間;需要運維人員在跟進過程中，需要學習更多的操作技能;更致命的是各個產品之間相互聯動和異構平臺支持的效果差，進而形成了各種維護的孤島。我的建議是企業可以乘系統升級改造的契機(比如說將實體服務器轉為虛擬機或轉向云服務等)，拿起“奧卡姆剃刀”，進行改造和整合。

說到虛擬化，大家都知道虛擬化的主要好處是可以通過整合來實現規模效應。由于大量的服務器、存儲和網絡集中在一個資源池中并被統一管理和按需配置，因此虛擬化已被各個企業IT系統所廣泛使用，成了邁向云服務的“入場券”。虛擬化平臺的容災保護，一般像SRM和Veeam采用的是虛擬化復制技術。打住，不多說這個了，哥再次重申我們的漫談說好的是vendor neutral的，大家沒有必要“來互相傷害”。因此，對于業務系統連續性要求較高和恢復時間苛刻的企業，一般都會選擇使用具有持續數據保護(CDP)特性的產品。從而達到對“任意時間點(Any Point-In-Time)”的細粒度數據訪問，實現秒級的恢時間目標 RTO降低恢復點目標 (RPO)。企業如果要擴容來，則可以采取旁路模式部署，只需增加備份或CDP節點，無需修改生產環境下的網絡架構，避免不必要的風險。另外，現在固態驅動器(SSD)的價錢降下來了。單單一塊磁盤就能獲得普通硬盤(HDD)同樣的工作負載性能。而且SSD還具有耗電量低、碳排放量少等優點。所以我們曾在硬件選型時重點考量過全閃存陣列 (AFA)。

大家也許會問到："云備份"和備份即服務 (BaaS)，以及災難復原即服務 (DRaaS)這樣的新概念。我個人覺得在技術實現和操作上基本沒問題，關鍵是觀念上的認可度的問題。人們總覺得數據放在公有云端后非自己所能完全掌控了。如今國內外各大云平臺提供商都已經能提供一整套完善的云備份的方案了，而且也已經有不少“吃螃蟹”的企業用戶了。所以關鍵還是看自己的業務系統。如果業務系統都已經使用或者搬到“云端”了，使用云備份趨勢想必也是勢在必行的了，it’s only a matter of time。我們就讓它“野蠻生長”吧。

備份與留存策略

我們應當根據現有存儲空間整體容量和系統使用開銷，并根據各個業務部門要求，逐個確定好每個子系統的數據備份和留存周期。比如說，您可以指定：快照每八個小時執行一次(可以僅工作時間);保留最近7天的快照;同時將每天的最后一份快照出庫一份到備份環境中，進行離線離場保護。每周二、四的初次備份采用全量備份，其余時間采用差分備份方式;而每月最后一份快照備份擴展保留1年，每一年最后一份快照備份則永久保留。這里只是些參考，具體策略一定要征求業務部門的同意，并最好能雙方確認留存。

事故發生前：勤練兵和更新

大家在日常工作中，可通過制定一份詳細的恢復演練計劃，并定期驗證數據保護的效果和災備數據的完整性。同時演練計劃還能提高運維人員的相關操作技能，既能未雨綢繆，還能提升業務水平，真是一舉兩得。另外，系統恢復后的檢查列表也很重要。一份好的check list既是對各項功能的梳理和自檢，又能方便大家排查盲點。因此千萬不可抱有一勞永逸的思想，要盡量保持及時更新和不斷改進。

這里不得不說到一個概念Call Tree，從名字上可知它有別于一般的聯系人列表。它更多包含的是If/then的關系的樹形結構，并在每個節點上有著primary/alternate的聯絡方式。它一般包括了當什么類型事件發生時，應該聯系誰(響應人員)和通知到誰(監管人員)，以及在某個節點無法聯系上時應該采取的流程等。這樣的列表不但要保證能分發到每個相關人員，而且在關鍵場地(如機房或call center)能觸手可及。同時保持相關人員聯系方式的定期更新也是非常重要的，不然真正事故發生了，大家一派焦(躁)郁(悶)(忙)碌的景象是誰都不想看到的。

事故處理中：厘清主次和關聯

一旦中斷事故發生了，大喊“Word天”是一種很low的行為。作為專業從業人員，我們一定要“淡定”。要根據需要馬上恢復的主要系統和次要系統的事先分類，進行輕重緩急、有條不紊的恢復。在實際操作中可以參照各種關鍵業務的最大允許中斷時間(Maximum Tolerable Downtime, MTD)。而這些數據一般來自于服務水平協議(SLA)，日常業務風險分析或是從企業年度內、外審中得到。

恢復過程中千萬別忘了各個子系統之間的相互關聯以及先后順序。比如說B系統一定要等A系統恢復運轉后才能順利進行，或者某些設備必須要等整個網絡起來后方可顯示為上線狀態等。

事故處理后：估值損率和“小目標”

多說一句，如今企業特別是上市公司都講求信息公開并對各類股東負責，所以一旦發生災難，信息安全人員乃至IT部門要能第一時間向領導層匯報損失。那么問題來了，如何才能迅速評估損失呢?最快的獲取方式是：從年度綜合保險的里找到資產清單，并參照日PV(page view)和交易量等數據便可得到。當然通過定期進行業務風險評估(Business Impact Assessment， BIA)，在事故發生前定義好各個子系統可能導致的定量(quantitative，如財務損失等)和定性(qualitative，如公司形象等)損失才是正道哦。不要問這方面我怎么搞得如此清楚，西湖的水，我的淚。。。。

最后再和大家分享一下有趣的事情，大型外企的災難恢復方案中最重要的目標不是系統的恢復，而是在場人員安全的保護哦。更有甚者還有人員精神及其家屬的安撫辦法。哥為他們這種不按套路的“傲嬌”出牌方式點贊!

至此，我們漫談系列的第一趴--系統技術部分和大家聊完了。我為自己能堅持到現在所感動，當然也離不開小伙伴們的積極互動與捧場。信息安全從來不是一個人的戰斗!常言道：“天青色等煙雨!”(什么鬼?自己去百度一下就知道了!哈哈)See U next time。

【51CTO.com 原創稿件，轉載請注明作者及出處。】