對于每一個企業來講，數據備份都是必不可少的一項關鍵性工作，它直接決定著企業能夠應對什么樣的數據威脅以及相應解決方案的靈活度和有效性。但是在IT飛速發展的今天，每一個企業的應用系統在不斷增加，數據類型在不斷的多樣化，數據的量級也在不斷的擴展。在這種形勢下，如何能把備份系統規劃的科學合理并且高效化是作為IT建設者必須考慮的問題。

本文通過大量的調研分析總結抽象出備份系統規劃時必須考慮的幾個關鍵性問題，并針對每一個問題進行分析和論述，提出解決思路。希望能給企業進行備份系統建設、改造或者升級的項目帶來一些啟示和幫助。

1.如何確定備份對象及備份策略

近些年來，企業的數據逐漸呈現多元化格局，從數據的模型層面可以分為結構化數據、半結構化數據、非結構化數據。從企業IT功能層面又可以將常見數據列為如下幾類：

• 關系型數據庫中保存的二維表數據。
• 非關系型數據庫中的文檔、JSON、鍵值等類型數據。
• 以文字方式記錄的文本、PDF、XML等文件形式的數據。
• 以二進制方式記錄形成的圖片、網頁等數據。
• 以視頻流方式記錄形成的媒體類數據。

作為企業來講，確定備份哪些數據對象，需要從數據重要性、數據量、數據特點等若干方面去評估。從企業業務角度評估的話，那么數據庫保存的數據一定是最重要的，尤其是關系型數據庫里面的二維表數據。其次需要根據行業特點以及具體的業務系統重要性來評估非結構化數據的重要性。

比如對于金融行業來講，記錄業務過程的一些影像類數據可能在業務審核過程中經常被調出查閱，這些數據雖然沒有結構化數據那么重要但是也是業務環節當中比不可少的元素，其重要性相對業務視頻類以及安防類視頻數據會高很多。但是如果是媒體行業的話，那么視頻類數據的重要性恰恰是支撐其業務的核心數據，其重要程度不言而喻。那么如何來決定哪些數據需要備份，以什么樣的策略備份？

首先，我們需要確定數據的重要性程度。本文通過結果導向的思路從以下維度來分析企業數據的重要性，最終決定哪些數據需要備份，哪些數據可以不備份，哪些數據需要根據企業的實際投資戰略情況來決定。

首先我們假定一個結果，那就是某個應用系統的某類型數據由于硬件故障或者其他原因導致數據丟失掉了。那么就看企業對該結果的容忍程度，假設不能容忍，那么就沒什么好商量的了，肯定要做備份。接下來，最重要的事情是我們如何定義數據備份的策略，包括備份的頻度、備份的模式、歸檔的檔期等等一系列備份作業元素。這部分內容需要考慮到數據本身的量級、數據的具體類型、極端條件下對數據恢復時間及數據丟失量的容忍程度、數據備份系統以及備份介質本身的性能特性、業務發展的規模及趨勢判斷等等。

本文從以下幾個原則來進行評估：

• 數據庫的備份既要有全量備份也要有歸檔日志的備份，全量備份可以根據數據量及重要程度以天為單位進行頻度調整；歸檔備份可以根據數據庫恢復區空間預留、歸檔增長趨勢、數據恢復時間要求、業務系統歸檔特點等多方面來進行以小時為單位的頻度調整和作業發起調用。
• 文件類型數據可以根據具體數據量來選擇是否利用傳統的文件復制方式來實現其備份，對于數據量大的情況可以采用存儲快照方式進行卷級別的復制代替以文件為單位的掃描復制方式。
• 系統備份作業的分布以及備份時間需要結合具體的備份窗口來進行合理調整，關鍵業務系統的備份作業不能影響到正常的業務，需要有強制的約束條件來約束備份作業時間跨度。尤其是全量備份，隨著業務不斷發展，數據量會與日俱增，如果對備份作業不進行任何調整，那么很有可能原有備份作業會超越備份窗口影響到業務性能。
• 根據具體的數據類型和業務重要性對所有備份作業進行分級管理。有些數據需要持續備份，有些數據可能只需要在特殊變更日進行備份即可，例如虛擬化的VMDK文件數據，完全沒有必要進行持續備份，只需要在變更后進行備份即可。

以上是對備份對象的確定以及如何把握具體的備份策略的分析和描述，具體細節及關鍵方法在接下來的章節會有詳細的剖析和介紹。

2.如何選擇備份架構的問題

2.1 備份系統涉及到的關鍵對象

所謂備份系統中的一些關鍵對象包括：備份軟件、備份介質、備份管理服務器、備份作業服務器、備份路徑等。這些關鍵元素共同組成了一個完成的備份系統。

• 備份軟件：常用的備份軟件包括IBM TSM、EMC Networker、SYMANTIC NBU等。
• 備份介質：常用的備份介質包括帶庫、EMC DATADomain、常規存儲等。
• 備份管理服務器：對備份作業進行配置調度并且保存備份元數據的集中管理節點。
• 備份作業服務器：具體執行備份作業的備份服務器。
• 備份路徑：每一個備份作業從客戶端采集數據到備份介質的整個路徑。

2.2 基于容災功能的備份架構

一般的企業可能只需要進行本地備份即可，但是對于某些行業尤其是金融行業，備份要求比較高，需要采用主數據中心和備數據中心聯動的高可用備份架構。具體如下圖所示：

整體架構從上到下分為三層：備份客戶端層、備份控制層以及數據存儲層。中間通過網絡（以太網絡或者是光纖網絡）相連接。紅色線表示控制信息流向，藍色線表示備份過程中的數據流向。

• 備份客戶端層，圖中最上面的部分既是。備份客戶端是我們要備份的數據對象存放的服務器，例如數據庫服務器、虛擬化平臺的VCenter、NAS服務器等。一般需要備份軟件的客戶端AGENT安裝到備份對象服務器上實現備份目標與備份服務器的通訊。
• 備份控制層，圖中中間的部分既是。主要包括備份主服務器和備份作業服務器，主服務器根據配置好的調度策略以及整體架構中的備份元素發送作業調度指令，并且將存儲片的元數據存儲到主服務器上的數據庫當中。然后作業服務器可以通過與客戶端的交互完成具體備份作業。元數據是具體備份片的索引信息、而真正的備份片數據會通過作業服務器送入備份介質當中，當我們對數據進行恢復時，首先需要對備份數據的元數據分析才能知道具體的數據備份位置及組合信息等，然后才能通過元數據的組織和具體備份片的恢復完成一個業務數據的完整恢復。
• 數據存儲層，圖中對下面的部分既是。實際上就是備份數據最終要存儲的地方，可以通過光纖網絡或者以太網絡實現其與備份控制層的連接。傳統模式一般會是光纖網絡和虛擬帶庫的組合模式，其優點在于備份速度和容量的性價比上。但是近些年來隨著以太網技術的發展，利用高速網絡實現的備份數據傳輸同樣可以保障其備份速度，同時具備更好的靈活性。所以近些年來利用萬兆以太網和DDBoast組合的方式也越來越多。

2.3 備份架構高可用性分析

整個備份系統的高可用性是由每一個部分服務的高可用配置來保障的，主要包括備份控制層、備份存儲介質層以及跨數據中心級別的高可用架構配置。下面我們分別來做剖析：

• 主備份服務器是整個備份系統的集中控制節點，其保存的元數據也是備份得以恢復的關鍵數據，因此為了保障主服務器的不間斷工作，需要保障主服務器為主備或者更高級別的高可用架構，元數據為所有本地主服務器共享，如圖2.2中所示的HA模式。
• 作業服務器是所有備份作業的執行者，必須將其組成一個備份作業服務器池，由這個備份作業服務器池向客戶端提供統一備份作業服務才能保障備份作業的不間斷性以及備份作業并發執行的性能，備份作業可以分布在不同的作業服務器節點上進行作業，如圖2.2中所示的負載均衡資源池模式。
• 從備份存儲介質層面上來看，為了保障備份作業無中斷目標，我們需要將兩個或者多個存儲介質設備綁定為一個虛擬的存儲介質池，當存儲介質發生故障時可以自動切換存儲介質設備，至少可以手動切換存儲介質設備。
• 容災角度來看，如圖2.2所示：兩個備份域之間備份介質可以通過光纖網絡層或者是以太網絡實現數據的異步復制，這樣可以保障真正的備份數據可以跨地域實現數據保護，但是光有這些數據我們無法實施數據恢復，因為數據恢復過程中最主要的是要根據元數據記錄的備份片索引及結構目錄找到真正的數據備份片實現完整的數據恢復。所以主備份服務器也要實現跨域界別的元數據復制。

3.如何解決非結構化數據備份的問題

3.1 非結構化數據備份面臨的困境

對于存儲在傳統NAS文件系統上的文件類數據，如果用通用的備份方法只能通過文件復制的方式來實現其全量和增量備份。但是隨著日積月累的非結構化數據增長，這類數據可能會從TB級別發展到10TB甚至PB級別。這類數據存儲組織的方式是文件系統的樹目錄形式，隨著數據的增加，其目錄的深度和規模也會呈現劇增趨勢。備份軟件在掃描文件目錄的時候會變得非常非常慢，最終導致備份作業慢到超過備份窗口的程度。

3.2 業務管理層面的解決方案

如果從業務管理層面來解決該問題的話，那么就是要讓備份作業在一定時間段內保持在合理的數據量范圍之內，也就是說要形成合理的多級數據緩存，根據數據使用頻度建立多級轉儲以及歸檔體系。保障使用頻度高的數據在日常備份作業范圍內，合理歸檔使用頻率非常低的歷史數據。拿金融行業的票據、信貸類系統來說，我們可以將合理業務周期內的非結構化數據存在在一級緩存當中，保障業務復核階段的數據讀取；將業務周期外的非結構化數據轉儲到二級NAS平臺上，保障近期內可能使用到的業務場景；將較長周期之前的數據定義為離線數據，歸檔到歸檔存儲設備當中。備份僅僅涉及到歸檔之前的數據。這樣既可以保障數據存取的性能，又能保障備份作業的長期穩定性，最終保障備份系統整體的安全穩定。

3.3 技術管理層面的解決方案

通過3.1章節對問題的原因分析，我們知道導致備份無法進行的原因在于備份軟件對于龐大文件系統目錄的掃描時間過長。那么順著這個思路，如果我們在備份的時候能避免去掃描整個文件系統目錄，而是通過別的方式來完成備份，就可以解決這個問題。通過調查研究我們發現目有兩種方法可以實現：

1）傳統NAS的快照方式。對于傳統的NAS存儲來講，快照是非常普遍的功能，通過NAS本身的快照復制，我們可以不用掃描文件系統沒目錄，僅僅基于某一個時刻點的快照，進行卷級別的復制實現全量備份；通過塊兒級別的對比實現增量備份，因為NAS設備底層還是基于塊兒設備實現的。當然這種技術需要對存儲本身的快照功能有非常強的依賴性。

2）分布式NAS存儲的日志記錄方式。某些基于分布式技術實現的NAS存儲可以對外提供日志操作的接口，也就是說對文件數據的增加和更新會記錄到存儲本身的底層日志當中，那么我們僅僅需要調用日志比對的接口就可以快速找到更新的目錄和文件，僅僅需要掃描更新的部分做增量的復制來完成備份。

以上的兩種技術方案需要我們在做備份規劃之前的選型階段對不同的備份軟件及存儲介質等進行深度調研和分析，盡可能科學合理組合實現以上解決方案。

4.如何解決平衡數據庫歸檔頻度和數據恢復完整性

4.1 數據庫恢復的基本原理

對于數據庫的恢復來說有很多種，我們只討論需要介質恢復的情況。在這種場合下，首先我們需要找到一個最近時刻點的全量備份進行恢復；然后需要從備份介質上找到這個時刻點之后的重做日志進行數據追平，***我們需要找到本地沒有丟失的重做日志進行再次追平直到沒有可用日志。如下圖所示：

如圖所示，在時刻A，我們開始做在線全庫備份，在B時刻全庫備份結束。當數據庫運行到E時刻之后數據庫發生了重大介質故障，只能通過介質恢復。那么在A~C時間段內，大部分REDO日志文件都已經歸檔到備份介質池當中，服務器本地存儲目錄當中只剩下C~E（小于一個歸檔備份時間間隔）的歸檔日志和沒有來得及歸檔的REDO日志文件。

假設發生的故障嚴重到服務器本地存儲目錄也無法恢復的時候，那么相當于在C-E這段時間產生的重做日志就丟失掉了。相當在這種極端場合下，數據丟失的***窗口就是一個歸檔間隔時間段。當然如果把這個間隔設置的足夠小的話，那么另外的問題就產生了，備份作業隨著系統增加會呈爆發式并發啟動狀態，最終會影響到整個備份系統的健康運行導致歸檔無法及時轉儲，最終還是可能會導致數據庫的宕機。這就是一個矛盾，需要我們去很好的平衡。

4.2 平衡數據庫歸檔頻率的方法

數據庫歸檔備份的頻率是指一天24小時內間隔多長時間進行一次歸檔日志的備份，一方面是要保障增量數據備份的完整性，另外一方面是要避免因為恢復空間不足導致數據庫的宕機時間。要平衡這個頻率窗口需要采集以下幾類數據：

1）單位時間內不同數據庫系統平均的歸檔日志量。

采集這個數據的目的在于詳細分析不同業務系統在不同時間段的寫操作頻繁程度。對于日志歸檔速度較快的系統，我們需要提高其恢復區的空間大小，同時加快歸檔備份的頻率，使得數據庫既能處于安全運行狀態又能保障極端故障場合下數據丟失的量在較小范圍之內。

2）業務系統類型。

所謂業務系統類型即OLTP或者是OLAP，因為對于OLAP來講，每次的讀寫操作都會是批量的執行，它的歸檔速度是正常OLAP系統的幾十倍甚至上百倍。最麻煩的是兩者皆有的業務系統，比如說銀行業中的交易系統，白天跑聯機交易，晚上跑核算批量，白天和晚上的日志歸檔速度有著巨大的反差。那么我們就需要在批量作業時間段內將備份頻率調快，將恢復區空間設置提高。

3）備份系統可以容忍的***并發量。

備份系統可以容忍的***并發Jobs，不僅僅取決于備份軟件系統可以并發調度的作業數目和備份作業服務器的數目，還要取決于備份介質池可以容忍的資源消耗限制。及時我們可以同時調度幾百個作業，但是當幾十個作業同時寫入備份介質池時就會把備份介質池的計算資源或者是IO資源使用殆盡。那么最終整個備份系統的并發數取決于短板因素。

4）不同數據庫系統恢復區能夠支撐最小時間窗口。

這個最小時間窗口是我們用數據庫的恢復區可用空間大小/單位時間內的***歸檔速度來估算出來的時間窗口。因為我們在安裝數據庫或者是做變更的時候不可能按照每一個系統的特點詳細計算出其日志存儲空間的大小，只能按照有限的幾個規格來做初始規劃。

有了以上數據之后，我們需要根據以下幾個原則來詳細設計我們的歸檔作業頻率。

首先，根據4當中采集到的數據，將時間窗口較小的幾個系統進行存儲空間調整，使其日志存儲空間能夠滿足我們期望的最小時間標準。

然后，將一天24小時定義為幾個時間段，批量業務集中的時間段、聯機業務集中的時間段、特殊任務集中的時間段等。當然這個定義主要是根據1&2中采集到的詳細數據來定義的。

接著，我們需要根據1中數據估算出一個歸檔作業大概持續的時間長度。為保障每一個時刻點的并發執行備份作業數目遠小于3中估算出來的數據。

***，需要把備份作業的頻度根據不同的時間段特點調整到以上條件都滿足的狀態，并在此前提條件下可以為了保障極端情況下的數據完整性而適當調快歸檔作業的備份頻率。下圖是一個根據以上采集數據進行多維分析的實例，僅僅是一個方法示意，歸檔頻率根據數據重要性分級、歸檔速度、業務時間段分類等前提進行的粗略分析，最下面的一行數字表示每一個時刻點并發的歸檔備份數目，其目標在于平衡每一個時間間隔內的平均備份作業數。實際情況會比以下情況復雜很多，我們可以將時間間隔劃分的更小，涉及的因素更多，分析的更加細致。、

5.如何評估數據庫全量備份的策略

數據庫的全量備份來講，隨著數據量的不斷增加，其備份作業耗費的時間也就會越長，耗費的數據庫資源也越多，對在線業務的影響也就越大。另外同一個時間段內發起的全量備份越多，那么其占用的備份系統整體資源（備份服務器、備份介質池、鏈路帶寬等）也就會越多，其影響范圍也會越廣。

首先，這個問題是一個需要不斷優化的問題。對于每一個應用系統來講，根據業務服務的特點，其備份的時間窗口也是不同的?？赡艹跗趥浞葑鳂I能夠在備份窗口內完成，但是隨著數據量的增長，后期的備份作業就會超過備份時間窗口。所以我們需要定期監控數據庫的全量備份作業時間，在事件窗口范圍內盡量通過調整合適的調度時間來完成全量備份。但是當數據量增長到完全沒辦法在備份窗口完成的時候，那么我們就需要進行調整全量備份的頻度和具體調度時間點了。

其次，這個問題是一個跟業務特點密切相關的的問題。有些人喜歡把所有的業務系統都按照一個標準去定義其數據庫全量備份的策略。比如說TB以下的數據庫，每天一次全量備份；比如說業務等級屬于重要的系統，每天一次全量備份；比如說只要能備份的系統，全部進行每天一次的全量備份等等策略。這些都是不科學的策略。應該從業務系統的數據重要性去評估數據庫全量備分的頻率，在現有備份系統有限的處理能力內保障數據重要性高的系統完成相應的全量備份。

***，這個問題是一個需要從各個方面著手去解決的問題。從備份網絡的帶寬和隔離性考慮，應該用單獨的告訴備份網絡，備份客戶端應該設置區分于業務的單獨網絡通道及配置。從備份作業服務器的配置層面，我們應該配置相對合理的資源（內存、磁盤）來保障備份片在作業服務器層沒有瓶頸。從備份介質池層面，我們需要保障備份介質的IO處理能力不能成為備份作業底端的性能瓶頸。

6.如何解決備份作業分布合理性問題

其實這個問題很簡單，目的就是要保障備份時間窗口內調度起來以及運行過程中的備份作業處于一種平衡狀態，不能使其作業調用或者是并發運行過于集中。但是當系統數目非常多，系統特點復雜，數據重要性級別有很多種，數據量以及數據增速各不相同時，這個問題就變得比較復雜。我們很難有一種精確的計算方法來實現其做到絕對，但是我們可以根據以下的方法進行定性的分析和調整。

假設我們定義一個系統的備份作業在備份體系當中必須具備的屬性為：

P1 - 應用系統數據的重要性級別屬性，可以通過業務分析劃分為有限的幾個級別。

P2 - 應用系統在不同時間段內的數據增量屬性，需要通過梳理歷史數據來評估。

P3 - 應用系統當前的備份作業的時間長度屬性，需要通過歷史數據結合數據量來評估。

P4 - 應用系統是否是具備雙重業務特性，比如兼備批量和聯機業務特性。

通過以上幾個屬性的加權計算或者其他方法的定性分析，計算出每一個系統的不同備份作業的定性矢量，然后我們可以將這些矢量根據其具體備份窗口設置初始的調度時間點，然后分析其具體分布圖是否均衡穩定并且進行微調。例如下圖是一個粗略的分析實例，可以提供相關的參考思路：

以上案例僅僅是一個相對粗略的分析方式，僅僅是一個基于某一特定案例的分析思路。我們可以根據業務系統特點結合更好的專業工具進行更加細節的分析。但是總體目標是讓我們的備份作業分布達到一定范圍內的平衡，另外在某些特定的業務場合或者特定的設備場合下，可能會有一些特殊的時間窗口需要和備份作業適當分割開來，比如說基于文件系統技術實現的備份介質存儲池，由于我們的周期性歸檔配置，它會定期去做文件系統的清理作業，而且時間段比較長，耗費資源比較高。我們盡量要講備份作業的分布策略與這些時間段保持適當的分割。這樣才會保證備份系統運行的長久安全穩定。

7.如何解決業務發展與備份系統有限性瓶頸

所謂的業務發展在備份體系建設過程中包括幾個方面的影響。一方面業務量的增長會導致備份作業的不斷增加，另外一方面業務量的增長會導致現有備份作業負載的不斷加劇，再有就是各種新業務的增加會帶來新型模式數據備份的挑戰。這幾方面的因素不但會對現有備份系統的負載擴展能力提出巨大挑戰，也會對現有備份系統功能擴展能力提出巨大挑戰。

解決以上問題，本文認為唯一可行的方法就是從單一傳統的備份系統逐漸過渡到完善的備份體系。傳統的備份軟件形成的格局只是這個體系的一個元素，基于快照的備份接口、基于軟件加速的接口、基于異構平臺轉儲的模塊兒都應該成為這個體系當中的擴展元素；同時備份介質也應該從單一的帶庫、DD等傳統備份介質擴展到由現有備份介質池和分布式存儲池、對象存儲池、云端備份池等多種元素組成的廣義備份介質池；單一的備份恢復模式也應該轉換為多級數據一體化模式，既包括多級數據的轉儲歸檔機制，又包括數據自動化下沉和上浮的機制，數據流向實現自動化平滑軌跡。

目前可以實現以上體系的軟硬件產品組合有很多，各家都有各家的特點和局限。關鍵是要靠規劃者根據自己的業務特點和長遠的發展預測來選擇和集成合適的解決方案。

8.總結和展望

本文基于企業備份系統建設過程遇到的一些問題進行深入調查和剖析，并切合企業具體問題案例從特定問題角度出發給出分析思路。隨著目前的分布式技術、云計算技術、互聯網技術等的不斷發展，備份體系建設的內容會呈現越來越多的新模式和新思路。

解決的方法也不局限于企業的數據中心內部，一些結合云計算的整體解決方案也在不斷誕生，它會涉及到數據的整個生命周期，當然這個根據不同的行業也會呈現不同的思路和模式。本文將次作為一個基礎性的思考，更重要的是希望能引起更多從業者從不同角度的思考和提煉，并分享出來供大家參考。

作者：趙海，在某城商銀行系統規劃設計中心任系統架構師，專注于銀行數據中心解決方案規劃及設計工作。他是twt社區“虛擬化”、“數據復制技術”等多個領域的專家。