典型問題與案例分析系統備份的前期規劃設計實踐

目前很多企業中備份環境存在的困境，大部分都是在前期的規劃設計方面存在不足，導致后期問題頻出，后期在運維或升級等方面都會顯得比較吃力。所以備份的前期規劃設計顯得尤為重要，本文針對社區會員提出的典型問題和場景案例，圍繞備份需求相關問題、備份設計相關問題、備份容災相關問題和場景案例四方面進行了分析解讀。本文問題和解讀內容由多位社區會員貢獻，匯總整理：王巧雷。1.

備份需求相關問題1.1如何界定自己的備份需求指標？【分析解讀】數據備份需求指標依據業務系統的特點和行業類數據保護管理的要求特點，容災備份較容易化管理量化指標RPO和RTO。數據系統按照等保管理規定的要求而制定備份相關指標。RPO：RecoveryPointObjectives，恢復點目標，可以理解為從丟失事件到最近一次在前備份的時間度量RTO：RecoveryTimeObjectives，恢復時間目標，理解為可以中斷或關閉多少時間而不會對業務造成重大損害1.2對所有的企業數據做備份代價較高，現實中也不具備條件，那么如何評估哪些數據需要做備份？數據規模越來越大，數據種類也多種多樣，除了存量系統的數據增長外，新增的IT系統或新采用的技術架構也會產生各種各樣的數據。對所有的企業數據做備份代價較高，現實中也不具備條件，那么如何評估這些數據是否需要做備份以及如何備份？【分析解讀】這個實際上還是備份需求的分析，需要在調研的時候對不同的應用數據做一個區分，個人總結了以下幾點：1.先區分下目的，一般情況下業務數據的使用都有冷熱特性。備份數據同樣也是，有的數據副本是為了應對數據丟失，這種是備份，特點是數據經常發生變化，保留周期相對較短，備份的頻率相對較多；有的副本是為了法規遵從，或者很小概率使用的歷史數據，這個對應歸檔，特點是基本不發生變化，保留周期長，備份頻率很少。2.

對數據類型分類，大體上我覺得可以是三種情況。數據庫（核心數據），非結構化數據（比如程序代碼，圖片，文檔），應用環境（應用業務的操作系統和應用配置環境），然后根據數據的重要性和可以接受丟失的程度來決定怎樣的備份手段。所數據都備份肯定是不現實的，備份目的是為了恢復，反向推，如果業務出現數據丟失，按最壞的情況算，都需要哪些數據，就備份哪些數據。然后再根據數據的特點設計，以Oracle為例，歸檔日志備份的頻率最高，數據文件次之，基礎環境最少，甚至可以不用備份。2.分類后的數據按照rto和rpo的指標設計備份策略即可，既要避免備份無法覆蓋需求，也要避免過度設計，浪費資源。3.根據業務數據實際需求進行分類，可以進行分級存儲存放設計，比如長期保存，且使用頻率極低的歸檔數據存放到磁帶庫，定期出庫離線保存，保證備份數據有效可查即可

中長期保存的備份數據，使用頻率較低的數據，可存放磁帶存儲、對象存儲或大容量低速磁盤存儲。短期保存視頻頻率較高的備份數據可存放到性能較高的磁盤池，后期酌情遷移到磁帶庫。1.3存儲備份系統按前端容量設計好，還是后端容量設計好？另外，備份帶寬的選擇如何確定比較好？【分析解讀】備份系統的規劃涉及到數據存量和增量的分析，數據類型的分析，備份窗口的分析以及未來發展的分析。建議：1.以業務系統出發，對備份內容，每天增量，備份策略，時間，都要有一個系統的評估，以此設計后端容量。備份存儲最終是存放備份后的業務數據的，數據在前端是一份，備份以后的容量受備份方式和保留策略影響，如果完全按前端容量對等設計后端，肯定是放不下的。設計時還要考慮其他因素，比如預留容量、后端是否采用了壓縮或去重等技術，這些都會影響最終的容量值。另外如果做了數據分層，需要根據各業務系統的分類做針對性設計，最終的目的存儲（比如帶庫）一定要滿足最終容量要求，或者滿足一次出庫周期。中間層的備份存儲（如vtl或重刪池）滿足一次遷移周期即可。2.帶寬方面，最低要求是在給定的窗口內完成數據備份。在這個前提下，根據實際環境和規劃來做帶寬設計，新環境有條件的可以按照規劃一步到位，老環境的升級改造可以按照長遠規劃，分批實施的原則來做。--備份作業和生產作業錯峰運行--采用高速網絡：萬兆ip網，16G或以上FC網--生產網絡和備份網絡隔離--設計或預留足夠的IO通道（如多網卡，多hba卡，多驅動器）--備份存儲的性能也是制約帶寬的一個因素，如有必要需升級或更換備份存儲2.

備份設計相關問題2.1備份體系建設如何適應未來五年的發展？傳統的備份體系，包括基于文件、數據庫、操作系統、虛擬機的備份；容器、大數據、微服務、各種云等新技術層出不窮。傳統的備份還能適應新時代的發展嗎，傳統的Symantec、TSM、Netwok等還能滿足現實需求不？備份體系建設如何適應未來五年的發展？在數據保護方面現在都有哪些新技術、新產品？【分析解讀】傳統備份軟件災備體系繼續可使用，發揮數據保護的作用。國內外災備服務商備份軟件繼續發布新的版本，新功能。比如云原生，容器，虛擬化，超融合，混合云，信創相關領域。1.時代和數據中心都在發展，備份的核心目標沒變，在給定的允許時間內，安全高效的創建數據副本。2.圍繞備份目標的工作還得做：需求分析、存儲規劃、調度規劃、容災規劃這些本質上沒太大變化。3.基礎架構方面，老的技術不斷增強，比如現在的萬兆網、16G的san，40G的infiniband，閃存存儲，甚至LTO9的驅動器；新的技術不斷涌現：壓縮、重刪、分布式存儲，云存儲、cdp等等4.傳統的備份產品在逐步兼容新技術，各大備份軟件都增加了對云存儲的支持，還有一些公有云、重刪、cdp等特性，模塊上也開始兼容更多的產品，比如nbu都已經支持openstack、容器、超融合等新技術的備份。5.也有新的產品和解決方案出現解決新的痛點，比如veeam，通過虛擬化備份做大后，一方面開始支持傳統unix平臺、nas、hana等場景，一方面也在收購kasten，做容器平臺的數據保護。6.綜合數據備份平臺很重要，覆蓋不到的新型業務也可以通過其他新技術來解決，后期再整合。綜上，備份體系本身也是隨著數據中心的發展而發展的，如果底層構建做的好，最大的問題可能就是多樣化的支持，這個一方面可以通過現有軟件的升級來完成，一方面可以引入新的解決方案，通過并行的方式來覆蓋所有的數據保護需求。2.2數據備份是否需要建本地備份服務器？是否需要根據本地的數據量大小和RTO的要求建立一個備份服務器用來保留最近幾天的數據？而不是數據直接落到磁帶庫。【分析解讀】可以，兩種實現方式1.庫不大的情況下，有的dba想自己備份，技術實力可以，先從腳本化方式或開源備份軟件bacula2.已經存在備份軟件。大多數的備份軟件都有分層存儲功能，備份的數據先落在磁盤存儲上，然后根據策略，在一定的時間后遷移到磁帶庫。這樣既保證了短期用到備份集時的效率，又能保證數據的長期存放。具體需要和備份管理員商量著來就行2.3怎樣制定合理的備份策略？【分析解讀】備份策略的規劃要從實際需求出發，參考自身的RPO和RTO指標來完成設計。要避免設計不足，達不到恢復需求；同時也要避免過度設計，浪費寶貴的存儲資源和計算資源。1.制定合理備份策略需求前期進行詳細的需求收集和需求分析，了解業務系統的詳細信息，包括數據量、數據類型、備份窗口等信息。2.需求分析完畢后對各業務系統進行分類，然后備份軟件按照分類將業務數據劃分到不同的策略，進行集中備份管理。一般情況下，策略的內容會包含備份主機、備份內容、備份頻率，備份保留周期等內容。在分類上可以基于以下維度：---基于相同的業務數據類型---基于相同的業務系統類型---基于相同的業務數據保留周期---相關聯、相依賴的業務系統組合3.調度規劃指的就是業務系統備份作業的發起窗口。不同的業務系統有自己的特性，在調度設計時要充分考慮備份作業對業務系統的影響。在調度規劃時要從多方面綜合考慮，要確保在不影響業務正常運行的情況下，在給定的備份窗口內完成數據備份，一般情況下規劃調度時，需要考慮如下因素：---業務主機備份的數據量和給定的備份窗口---備份服務器的資源負載程度---備份網絡環境的負載程度---業務方面的其他特殊要求總結：調度的規劃要根據實際業務做好平衡，整體上來要根據調研的結果盡量去滿足各個業務系統的備份要求，但如果這個需求超出了整個備份系統的能力，需要從其他方面做出考慮。2.4

怎樣進行備份存儲和備份網絡的規劃設計？【分析解讀】可以從以下幾個點來考慮：1.通過備份需要調研，確定存儲空間的用量。首先應該先調研并匯總，確認整個環境中當前要需要備份的系統有多少，各大概有多少數據量，最終得到1個初步的數據總量。其次，應該了解并估算整個備份環境的增長量，以及規劃的年數。比如，初步估算所有的備份數據總量為5T，每年增長20%，規劃5年周期。最后的總量應該是12.5T左右最后，要確認保存的周期或保存的副本數。比如，初步按3個副本保存，40T的有效容量應該是沒問題的。2.根據存儲空間初步確定設備選型。根據需求選擇存儲，目前可供選擇的有磁盤存儲、一體機、云存儲（含本地對象存儲、私有云和公有云、磁帶庫等，比如有離線保存需求，則一定要使用物理帶庫。存儲選型時，可以優先考慮含高級特性的存儲或一體機，比如重刪、快照等技術。3.備份窗口的確定通過和業務系統的負責人的溝通，了解每個要備份的業務系統的最大備份窗口，根據備份窗口選擇合適的備份方式，最終獲取備份速度指標。4.備份網絡需要獨立設計要求和生產網絡隔離，前端網絡盡量使用萬兆網絡，采用獨立的網絡設備；后端san網絡也要獨立使用，和生產存儲的分開，盡量使用較新的16G網絡，根據備份速度要求，做好預留，使用多通道技術提升備份速度。3.

備份容災相關問題3.1如何進行備份容災設計，如何與已有的災備系統匹配？【分析解讀】常見有以下幾種模式：1.主中心備份到磁帶庫，定期做磁帶出庫，將磁帶運輸到備中心保存，備中心可選設計一套備份系統用來做恢復驗證。嚴格意義上來講，這只能算是備份介質的異地存放，不能算容災。2.主備中心獨立部署備份系統。在主備中心已經基于業務或數據層面做了數據同步的情況下，這種方式實際上是部署了兩套獨立的備份系統，兩套備份軟件在數據和架構上都是獨立的。3.主備中心采用了相同備份存儲，并且基于備份存儲層面做了數據同步。備份軟件直接使用同步后的數據。這種方式下，備份軟件獨立部署，但是備份數據存在復制關聯。4.主備中心采用了相同的備份軟件平臺，并且做了基于備份軟件的數據同步，一般情況下，同步會基于重刪和壓縮技術來減少數據傳輸量。比如TSM的nodereplication復制，NBU的air等。具體使用哪種容災備份模式，并沒有一定的成例。需要結合企業自身的實際情況，選擇最合適自己的。另外，備份容災的規劃可以放長遠一些，分階段逐步完成，沒有必要一蹴而就。3.2數據容災設計和容災備份是基于何種備份？數據容災設計和容災備份是基于何種備份？是基于網絡存儲、虛擬化、還是云備份？安全性、可靠性和智能糾錯方面如何？【分析解讀】容災備份是容災設計的一部分，通常我們說的容災大部分情況下都是指業務系統的容災。容災備份指的是備份系統在容災系統中的實現。這個目前沒有統一的標準和要求，一般有如下幾種方式，企業可以結合自己的實際情況來實現。1.生產和備份中心的備份系統各做各的，沒有關聯。因為業務系統已經做了容災，所以也可以認為備份數據有兩份，只是從備份系統的角度來，是各自獨立的，備份發生了兩次。2.通過備份存儲實現備份容災。兩個數據中心都使用了相同品牌的存儲，并且存儲直接具備數據復制功能，可以確保一個中心的備份數據傳送到另一個中心，備份數據也是兩份，備份發生了一次。3.通過備份軟件實現，現在很多備份軟件自身都有容災選項，比如nbu的air，tsm的nodereplication等，也可以實現一次備份，兩中心的副本。4.在上述3點的基礎上，結合分級存儲或者磁帶出庫，可達到更靈活的設計方式。3.3commvault做異地2copy吞吐量一直上不去？用commvault做從北京硬盤到廣州的2copy操作，專線帶寬300M，一直占用100M，吞吐量80G/小時。問一下社區專家，commvault是不是有限制帶寬使用的參數？如何充分利用專線帶寬？【分析解讀】1.首先拋開備份軟件，單獨做一下普通文件的復制，看一下帶寬能到多少，排除一下帶寬本身的問題。2.再從CV的角度來看，commvault的異地拷貝一般是DASH拷貝方式，從源磁盤庫只傳輸變化的數據塊到目標端磁盤庫，有兩種模式：網絡優化：

源端MA讀取需要拷貝數據塊的Hash值，先與本地SSDB比對，沒有匹配項再與目標端MA的DDB比對。可以降低Hash在網絡中的傳輸，減少網絡流量，適用于低帶寬環境下的數據拷貝。磁盤讀取優化：

源端MA讀取需要拷貝數據塊的Hash值，再將Hash值通過網絡傳到目標端MA進行比對，適合高速網絡環境下的數據拷貝。你這種情況應該是網絡優化模式，確認一下是否源或目標端的MA服務器處理器或磁盤讀取性能壓力比較大4.

場景案例4.1

如何備份有共享盤的VMware虛機?我使用networker備份虛機，但有一點，一旦VMware虛機有共享盤，則無法備份，連快照都不能做，只能通過rman備份數據庫，但系統就無法備份。哪位兄弟備份過有共享盤的VMware虛機，兄弟指點一下?【分析解讀】首先，VMware的共享盤設置必須是獨立持久的,否則用不了，但卻無法做快照。而包括networker在內的大部分備份軟件，備份VMware都是調用VMware的接口，如果無法做快照是沒辦法備份的。需要按照物理機的方式去備份。至于系統和文件可以采用下面幾種方式：1.通過文件備份備份系統內的重要文件，也就是在虛擬機里安裝備份軟件客