數據保護和備份概述

 

數據保護

---

 

所謂數據保護是指對當前時間點上的數據進行備份，如果說一份數據被誤刪除了，可以通過備份數據找回來。從底層來分，數據保護可以分為文件級保護和塊級保護。

 

文件級備份

文件級備份：將磁盤上所有文件通過調用文件系統接口備份到另一個介質上。也就是把數據以文件形式讀出，然后存儲在另一個介質上面。此時備份軟件只能感知到文件這一層。

 

　　我們知道一般來說，文件在原來的介質上，可以是不連續存放的，通過文件系統來管理和訪問。當備份到新的介質上以后，文件完全可以連續存放。正因為如此，沒有必要備份元數據，因為利用新介質進行恢復的時候，反正會重構文件系統。

 

塊級備份

塊級備份：就是不管塊上是否有數據，不考慮文件系統的邏輯，備份塊設備上的每個塊。

 

　　這樣好處是不通過調用文件系統接口，速度更快，缺點的是備份的時候會把所有的塊復制一遍，但是實際上很多扇區的數據是不對應真實文件的，也就是會備份很多僵屍扇區。而且備份之后，原來不連續的文件一樣是不連續的文件，有很多的碎片。

這種方式的一個典型案例就是磁盤鏡像。而磁盤鏡像最簡單的實現方式就是RAID1。

 

 

 

 

高級數據保護方法

---

 

遠程文件復制

遠程文件復制：通過網絡傳輸到異地容災點。典型的代表是rsync異步遠程文件同步軟件。可以監視文件系統的動作，將文件的變化，同步到異地站點。增量復制。

 

遠程卷鏡像

這是基於塊的遠程備份。與遠程文件復制不同的地方在於，是把塊數據備份到異地站點。又可以分為同步和異步復制。

 

• 同步復制：必須等數據復制到異地站點以后，才通報上層IO成功消息

• 異步復制：寫入成功即可回復成功，然后通過網絡傳輸到異地。不能保證一致性，但是上層響應快。

 

　　基於塊的備份措施，一般都是在底層設備上進行，不耗費主機資源。

 

       

 

快照

　　遠程鏡像確實是對生產數據一種非常好的保護，但是需要鏡像卷一直在線，主卷有寫IO，那么鏡像卷也需要有寫IO。

 

　　如果想對鏡像卷進行備份，需要將停止主卷的讀寫，然后將兩個卷的鏡像關系分離。所以當恢復主卷的IO的時候，鏡像卷不會再被讀寫。然后才可以備份鏡像卷的數據。

 

　　這樣會存在一個問題，主卷上還繼續有IO，將會導致數據與備份的鏡像不一致。所以主卷上所有的寫IO動作，會以位圖BitMap方式記錄下來，BitMap上的每個位表示卷上的一個塊，0表示未寫入，1表示已寫入，所以當拆分鏡像以后，被寫入了數據，程序將BitMap文件對應位從0變為1。備份完成以后，再做數據同步即可。

 

　　可以看出上述過程比較的繁瑣，而且需要占用一塊和主卷一樣大小的鏡像卷。

 

    

 

　　快照技術就是為了解決這種問題，其基本思想是抓取某一時間點磁盤卷上的所有數據。

 

基於文件系統的快照

 

文件系統管理的精髓：鏈表、B樹、位圖，也就是元數據。

 

　文件系統

• 將扇區組合成更大的邏輯塊來降低管理規模。NTFS最大塊可以到4KB，也就是8個扇區一組一個簇(Block)，這樣可以減少管理成本，但存儲空間可能會造成浪費。

• 文件系統會創建所管理存儲空間上所有簇的位圖文件。每個位代表卷上的簇(或者物理扇區)是否被使用，如果被使用，則置1。

• 文件系統保存一份文件和其對應簇號的映射鏈。因為映射鏈本身和簇位圖也是文件，也有自己的映射鏈，所以針對重要的元數據，有一個固定的入口: root inode。

 

　寫入新數據

• 查找簇位圖，找位值為0的簇號

• 計算所需空間， 分配簇號給文件

• 將數據寫入簇，再去文件簇號映射鏈更新

• 將對應的簇映射關系記錄下來，到簇位圖將對應位置改為1。

 

　刪除數據

• 直接在簇號映射鏈中抹掉

• 簇位圖對應簇改為0。

 

　　可以看出刪除數據實際上不會抹掉實際的數據。所以，最重要的不是數據，而是文件簇號映射鏈和位圖等元數據。

 

    

 

　　也就是說我們要做備份，只需要把某時刻的文件系統中的映射圖表保存下來。但是必須保證卷上的數據不被IO寫入了，同時又要保證應用還不能中斷。既然原來的空間不能再寫了，我們可以寫到其他的空閑區域。

 

• 思路一：Copy on First Write (CoFW)，在覆蓋數據塊之前，需要將被覆蓋的數據塊內容復制出來，放到空閑的空間。

• 系統中將有兩套元數據鏈，原來的元數據指向當前，快照的元數據鏈指向歷史。原來的存儲空間永遠是最新的數據，歷史數據會逐漸搬出到空閑空間里面。

 

     

    

• 思路二：Redirect on First Write (RoFW)。先復制元數據，然后將針對源文件的更改都重定向到空余空間，同時更新元數據。

• 與CoFW不同的是，原來的數據塊不會被覆蓋。同樣的，系統也有兩套元數據，一套是快照保存下來的，永遠不更新，一套是源文件系統的，不斷的更新。

   

　　其實只有首次覆蓋的時候，才重定向，因為重定向以后的數據塊，哪怕被覆蓋了，也不影響之前快照保存的數據了。

 

　　到這一步，看上去挺完美，實際上存在一個問題: 如果元數據特別大怎么辦？對於海量龐大的文件系統，元數據量可能到GB級別。如果復制的話，時間上仍然太多。

 

　　我們可以回頭想想，實際上元數據可以看做指針，指向具體存儲的位置。我們復制到元數據，相當於復制了一堆指針。現在元數據太多了，我們能不能把這個元數據鏈的指針給復制了？當然可以，元數據有個根入口塊，或者稱為Super Block，這個塊是固定不變的，里面存放有指向下一級元數據鏈塊的指針。

 

　　那么操作系統每次載入元數據的時候，都需要從這個地址讀入Super Block，從而一層一層的遍歷。我們還是按同樣的方法，只復制Super Block的信息，那么其下所有元數據鏈自身的變更也要進入快照流程。

 

基於物理卷的快照

 

　　基於物理卷的快照比文件系統快照要簡單得多。因為LUN一般在底層磁盤上是恆定的，不像文件系統一樣可以隨機細粒度的分布。所以可以認為LUN的元數據就是在底層磁盤的起始和結束地址。這樣在快照的時候，需要復制的元數據就更少了，但是完成了以后，需要按照一定粒度來做CoFW或者RoFW，還需要記錄更多數據映射指針，就比較難受了。

 

　　對於實現了塊級虛擬化的系統如NetApp、XIV、3PAR等，它們的LUN在底層位置是不固定的，LUN就相當於一個文件，存在元數據鏈來進行映射管理的維護，所以這些系統實現快照的原理與文件系統快照類似。

 

　　基於物理卷的快照，相當於給物理卷增加了“卷扇區映射管理系統”。在底層卷實現快照，可以減輕文件系統的負擔。

 

　　卷扇區方都是用LBA來編號的，實現快照的時候，程序首先保留一張初始LBA表，每當有新的寫入請求的時候，重定向到另一個地方，並在初始的LBA表中做好記錄，比如:

 

原始LBA：卷A的10000號，映射到LBA：卷B的100號。

 

　　值得說明的是，文件系統無法感知重定向，文件系統在它的映射圖里面還是記錄了原始的LBA地址。此時如果來了新的寫IO，有兩種方式一種是Write Redirect，另外一種是Copy on Write。

 

　　所謂Write Redirect就是將文件系統的讀寫請求，重定向到卷B，這樣每次IO其實都會查找快照映射表，降低了性能。所以引入了Copy on Write。

 

　　所謂Copy on write，就是當寫請求來的時候，先把原來的扇區的數據復制一份到空閑卷，然后將新數據寫入原卷。不過這種復制操作只發生在原卷某個或者快照之后從未更新過的塊上面，若是某個塊在快照之后更新過了，說明之前的數據已經轉移走了，可以放心的覆蓋。

 

　　所以Copy on Write實際上是讓舊數據先占着位置，等新數據來了以后先把原來的數據復制走，再更新，而且一旦更新了一次，可以直接覆蓋。

 

　　帶來的好處是 ，原卷上的數據隨時是最新的狀態，每個IO可以直接訪問原卷的地址，而不需要遍歷映射表。

 

     

 

RoFW方式與CoFW方式比較

 

　　不管是RoFW還是CoFW,只要上層向快照后沒有更新過的數據塊進行寫，都需要占用一個新的塊。所以如果將所有扇區塊都更新了，新卷的容量和原來的容量應該一樣大，但是通常不會覆蓋百分之百，所以只要預設原容量的30%即可。

 

　　IO資源消耗：

 

• CoFW方式下，如果要更新一個從未更新的塊，需要復制出來，寫到新卷，然后覆蓋原來的塊，需要一次讀，2寫。

• RoFW方式下，只需要一次寫即可，也就是直接重定向到新卷上，然后更新映射圖中的指(在內存中進行)。

   

所以RoFW相對CoFW方式在IO資源消耗與IO延遲上有優勢。

 

　　由於只有首次覆蓋才會Copy或者Redirect，那么如何區分是否是首次覆蓋呢？可以使用記錄表(文件級快照)或者位圖(卷快照)來記錄每個塊是否被覆蓋過。

 

　　對於讀IO：

 

• CoFW：因為總是更新的源卷，所以源卷總是代表最新的狀態，所以任何讀IO都會發到源來執行。

• RoFW：需要首先查詢位圖來確定目標地址是否被處理過，如果是，則轉向重定向后的地址。

 

　　RoFW會影響讀性能，因為重定向出去以后，數據塊排布都是亂的，如果把快照刪除后，不好清理戰場，嚴重影響后續的讀寫性能。

 

　　綜合來說，RoFW比較吃計算資源，而CoFW比較耗費IO資源。我們知道其實一般來說讀比寫多，當覆蓋第二次以后：

 

• CoFW不會發生IO懲罰，讀IO一直沒有懲罰

• 對於RoFW，就算完全被Redirect過了，對於讀或者寫IO，均需要遍歷位圖，永遠無法擺脫對計算資源的消耗。

 

　　尤其在LUN卷級快照下，原本卷在底層磁盤分布式是定死的，尋址非常迅速。但是RoFW引入了，LUN的塊隨機定向到其他的空間的，所以需要記錄新的指針鏈，而且被寫出的塊不是連續排列的。對性能影響非常明顯的。

 

　　絕大多數的廠商使用的還是CoFW，但是一些本來就使用LUN隨機分塊分布模式的存儲系統比如XIV、NetApp等，都使用RoFW，因為原本其LUN的元數據鏈就很復雜，而且原來就是隨機分布的，RoFW的后遺症對它們反而是正常的。

 

       

 

快照的意義

 

　　快照所保存下來的卷數據，相當於一次意外掉電之后卷上的數據。怎么理解?

　　上層應用和文件系統都有緩存，文件系統緩存的是文件系統的元數據和文件的實體數據。每隔一段時間批量Flush到磁盤上。而且不是只做一次IO，有可能會對磁盤做多次IO。如果快照生成的時間恰恰在這連續的IO之間，那么此時卷上的數據實際上有可能不一致。

 

　　文件系統的機制是先寫入數據到磁盤，元數據保存在緩存里面，最后再寫元數據。因為如果先寫元數據，突然斷電了，那么元數據對應的僵屍扇區的數據會被認為是文件的，顯然后果不堪設想。

 

總之，快照極可能生成不一致的數據。

 

 

　　那么為什么還要用快照呢？

　　因為快照可以任意生成，而且占用的空間又不大，更重要的是可以在線恢復，不用停機只需要在內存中做IO重定向，那么上層訪問就變成以前時間點的數據了。

 

　　但是快照會存在不一致的問題，如何解決？

　　既然快照無異於一次磁盤掉電，那么利用快照恢復數據之后，文件系統可以進行一致性檢查，數據庫也會利用日志來使數據文件處於一致。

 

　　在微軟的Windows Server平台上，利用Windows Volume Shadow Copy Services (VSS)和它的API，數據庫應用程序可以集成並調用快照工具。

　　VSS是專門為結構化數據應用設計的服務框架，可以驅動數據庫等應用進入數據一致性的靜止狀態，在快照開始初始化之前，完成刷新緩存、結束寫操作以及系統狀態的更新。

　　

　　遺憾的是，目前在Linux和Unix操作系統平台上還沒有類似VSS的服務或API。VMware公司的vCenter storage API可以說是一個部分解決方案。快照的發起者可以通過vCenter storage API給vCenter發出一個指令，讓虛擬機進入靜止狀態，然后再執行快照。但這個時候，快照由於沒有通過應用程序感知，也許會存在不一致的問題。

 

　　另外，現在主流的快照解決方案是在主機上安裝一個代理，執行快照前，先通知文件系統將緩存中的數據全部Flush到磁盤，然后立即生成快照。

 

---

 

　　快照另外一個非常重要的特性是快照一致性組（Consistency Group），這個功能就是支持多個LUN或者叫卷volume同時做快照，保證數據的一致性。

 

　　如果采用陣列的快照來做數據庫的備份，必須所有的LUN都是一個時間點的才行，這樣數據庫恢復的時候才能起來，否則數據庫必須回滾到某一個一致的時間點，意味數據的丟失。

 

　　比較完美的做法就是在主機安裝一個快照的agent，最好是多路徑軟件具備這個功能，在高端存儲要做快照的時候，對主機的快照agent說，別動， 要照相了。

　　主機agent接受到攝影師的命令后，把ORACEL主機緩存的內容flush一下到陳列來，然后hold住，陣列也盡快把cache的內容flush到硬盤里，ORACLE用到的所有硬盤一塊喊”茄子“，攝像師一按快門，一幅完美的快照就產生了。

 

　　一致性組除了保證照相的時候一致性外，還有恢復的時候要一致性恢復。這塊的實現的重要性就不如照相的時候重要，可以人工選擇同一時間的LUN快照恢復就可以了。最重要的是照相的時候必須要一致，而且這個人工干不了。

 

• 快照還可以預防數據邏輯損壞，也就是比如T1時刻，做了快照，T2時刻，因為管理員操作不當，誤刪了一個文件，T3的時候，進行了全備份操作。此時，這個文件看似永久丟失了，其實，此時還可以通過快照恢復這個文件。

• 快照還可以降低一致性備份的窗口。如果沒有快照，要對某個卷進行一致性備份，需要暫停寫IO，所以備份窗口比較長，需要等待備份停止以后才能繼續寫IO。使用快照的話，只需要復制元數據，然后在后台進行備份，降低了影響。

• 備份完畢以后，如何能檢測數據是否是真一致的？若沒有快照，需要將備份數據恢復到獨立的物理空間里面，掛載到另一台機器上。有了快照，可以將快照直接掛載到另一台主機，避免了數據物理恢復導入的過程。

 

 

 

 

克隆

　　快照類似於某時刻的影子，而克隆則是某時刻的實體。每時刻生成了一份可寫的快照，就叫對卷某時刻的一份Clone。然后這份Clone內容沒被修改的部分是與源卷共享的，所以源卷沒了，則Clone就沒了，所以叫虛擬Clone。如果把數據復制出來，生成一個獨立的卷，則就叫Split Clone，也就是可以得到實Clone。

 

　　卷Clone最大的好處在於可以瞬間生成針對某個卷可寫的鏡像，而不管卷的數據量有多大。

 

 

連續數據保護（continuous data protect）

　　CDP是一種在不影響主要數據運行的前提下，可以實現持續捕捉或跟蹤目標數據所發生的的任何變化，並且能夠恢復到此前任意時間點的方法。

 

　　CDP系統能提供塊級、文件級和應用級的備份。

 

　　所謂應用級CDP，是說對數據的連續保護機制是發生在應用程序層的，換句話說，由應用程序自己對自己的數據加以連續保護，記錄和保存每一筆更改。

 

　　應用級CDP的典型例子就是比如Oracle和DB2等各種數據庫系統，數據庫系統對每一筆交易都會進行日志記錄，在歸檔日志模式下，所有曾經對數據庫進行的更改操作均會被打入時間戳並記錄到日志中，老日志不斷地被歸檔存放以便為新日志騰出空間。當數據庫發生問題的時候，利用歸檔的日志，就能夠將數據庫狀態恢復到任何一個指定的時間點，數據庫會順序讀出庫中的每一筆交易然后將其重放（Replay），對應的數據重新寫入數據庫文件。重放完成后，還需要進行Redo和Undo操作，即檢查日志中最后一個CheckPoint一致點處，一致點之后發生的交易全部回退。回退完成后，數據庫便處於一個一致的狀態並且可用。應用層CDP不需要任何其他程序的輔助，不需要任何特殊的存儲系統功能，完全由應用程序自身就可以完成。

 

　　應用級CDP是最純粹、最厚道、最徹底、最實用的CDP。

 

　　文件級CDP就是通過監視文件系統動作，文件的每一次變化（包括實際數據或者元數據的變化，比如重命名、刪除、裁剪等屬性的改變） 以日志的形式被記錄下來。CDP引擎分析應用對文件系統的IO數據流，然后計算出文件變化的部分，將其保存在CDP倉庫設備（存放CDP數據的介質）中，可以針對每個文件生成單獨的日志鏈。可以對一個文件，或者一個目錄，甚至一個卷來監控。

 

　　文件級的CDP方案，一般需要在生產主機上安裝代理，用來監控文件系統IO，並將變化的數據信息傳送到CDP倉庫介質中，或者使用本地文件系統或者磁盤的某塊額外空間來充當日志倉庫。

 

　　文件級的CDP，能夠保證數據的一致性。因為它是作用於文件系統層次，捕獲的是完整事務操作。所有的文件版本管理軟件都可以算作是文件級CDP的實現。

 

　　其實日志型文件系統自身也可以算作是一個粗線條的CDP實現，因為日志型文件系統自身也會記錄每一筆操作記錄和數據，只不過其日志是循環的，並非歸檔模式，同時默認的日志方式是只記錄元數據更改而不記錄實際數據，並且也不提供用戶自定義回溯時間點的功能。如果能 夠直接在文件系統模塊中或者外嵌一個模塊來針對每個文件記錄歸檔模式的元數據＋實際數據日志，那么恢復的時候就可以指定某個文件的某 個時間點進行數據回滾了。

 

　　塊級的CDP，與應用級和文件級的CDP實現思想相同，其實就是捕獲底層卷的寫IO變化，並將每次變化的塊數據打入時間戳並且保存下來。

 

　　基於數據塊的數據保護又可以分為基於主機層、基於傳輸層和基於存儲層三類實現方式。一般來講，基於塊的持續數據保護除在主機層實現以外，相關的產品和技術比較復雜，實施成本也相應地比較高，因此適合於有持續數據保護需求的大中型企業。

 

　　CDP持續數據保護技術分為真CDP(True CDP)和准CDP(Near CDP)兩類。　　

　　CDP的分類是相對於數據保護時間點而言的。准CDP技術是按照一定的時間頻率，持續的記錄並備份數據變化，每次備份有一定時間窗口，需要數據恢復時，可以恢復到過去備份的時間點，並不能形成完全意義上的持續保護，因此稱為准CDP技術。　　

　　而真CDP技術是持續不間斷的監控並備份數據變化，可以恢復到過去任意時間點，是真正的實時備份。

 

 

 

VSS公共快照

　　VSS全稱是Volume Shadow copy Service，即“卷影復制服務”

 

　　上面提到，snapshot會生成不一致的數據，為了保證snapshot的一致性，幾乎所有的存儲廠商都提供了自己開發的針對各種應用程序和文件系統的代理模塊。而應用程序有無限多種，存儲廠商也有多個，與其每一個廠商為每一種應用程序都開發自己的代理，不如在操作系統中建立一個公共的framework服務，往上適配各種應用程序，往下適配各廠商的代理，做到統一控制調配，統一開發接口。微軟在其windows server操作系統中就提供了這樣一種公共服務模塊，這就是VSS模塊被開發的初衷。

 

　　下圖是VSS架構：

　　

 

　　整個VSS邏輯架構包含4部分：VSS核心服務，writer，provider，requestor

• writer

　　　　代表各種應用程序，這些應用程序必須支持VSS，運行時便向VSS進行注冊。VSS核心服務提供SDK開發接口

• provider

　　　　各個底層存儲系統中的快照提供者，說白了就是各個存儲廠商的存儲系統以及在其主機端的代理程序，存儲系統必須只是snapshot

• requestor

　　　　代表各個存儲廠商的快照管理程序，當然也可以是快照代理程序，這個程序負責何時出發快照，管理員通過配置來控制快照生成的時間點和頻率等

 

　　流程：

• T1時刻，某應用程序正在運行，並不停向卷LUN1寫入數據

• T2時刻，系統管理員需要針對LUN1出發一次快照，管理員打開對應存儲廠商的requestor程序界面，手動出發snapshot

• T3時刻，requestor程序接收到了管理員的操作，然后立即向VSS請求目前所有在VSS中注冊的writer列表返給自己。

• requestor判斷writer是否在列表中，如果在，提取注冊信息，想VSS發起請求，通知VSS快照請求已經發起，請協助處理后續事宜

• T4時刻VSS收到requestor請求后，根據傳送的卷列表信息向所有的provider發起查詢誰可以針對LUN1進行快照，對應的provider收到查詢后應答

• T5時刻，VSS此時已經得知了所有的必要信息，即哪個應用，哪個卷，哪個provider，VSS立即向writer發起請求，讓writer暫時生成一致點，沒完成的運算趕緊完成，來不及完成就暫掛，將緩存中的數據該回退就回退，並且暫停對數據卷的寫IO操作。writer完成這些之后會通知VSS

• VSS接收到writer已經准備好的通知后，立即向對應的provider發起執行快照的請求，provider收到VSS指令后立即與存儲設備通信針對LUN1生成快照

• 一旦快照生成，provider通知VSS快照已生成，VSS再告知writer可以繼續正常工作了，然后VSS通知requestor本次快照成功生成

• 系統恢復常態

 

 

備份系統

---

  

備份目標

指將備份對象的數據備份到何處

 

備份到本地磁盤

 

　　備份目的地是在本地的磁盤，則只需要將數據備份到本地磁盤的另外分區中或者目錄中。這樣不需要網絡，缺點是對備份對象自己的性能影響大。還會對其他的IO密集型程序造成影響。

 

　　這種方式一般用於不關鍵的應用和非IO密集型應用。比如E-mail，對轉發實時性要求不高。

 

備份到SAN上的磁盤

 

　　備份到SAN上的磁盤，就是將需要備份的數據，從本地磁盤讀入內存，再寫入HBA卡緩沖區，然后再通過線纜傳送到磁盤陣列上。

 

• 優點：只耗費SAN公用網絡帶寬，對主體影響小。

• 缺點：對公共網絡資源和出口帶寬有影響。

 

備份到NAS目錄

 

　　備份到NAS目錄就是將數據備份到遠程共享目錄中。比如window中常用的文件夾共享。因為數據一般是通過以太網進行傳遞的，占用了前端的網絡帶寬，但是相對廉價，不需要部署SAN。

 

備份到磁帶庫

 

　　現在出現一種虛擬磁帶庫，即用磁盤來模擬磁帶，對主機來說看到的是一台磁帶庫，實際上是一台磁盤陣列，主機照樣使用磁帶庫一樣來使用虛擬磁帶庫。要做到這點，就必須在磁盤陣列的控制器上做虛擬化操作，也就是實現協議轉換器的作用。可以帶來了的好處是：

• 速度提升

• 避免機械手這種復雜的機械裝置，取而代之的事控制器上的電路板

• 管理方便，隨意增刪虛擬磁帶

 

 

備份通路

備份經過的路徑

 

本地備份

 

數據流向：本地磁盤——總線——磁盤控制器——總線——內存——總線——磁盤控制器——總線——本地磁盤。

 

　　也即數據從本地磁盤出發，經過本地的總線 和內存，經過CPU少量控制邏輯代碼之后，流回本地磁盤。

 

通過前端網絡備份

 

經過前端網絡備份的數據流向是：本地磁盤——總線——磁盤控制器——總線——內存——總線——以太網卡——網線——以太網——網線——目標計算機的網卡——總線——內存——總線——目標計算機的磁盤。

 

　　數據從本地磁盤出發，流經本地總線和內存，然后流到本地網卡，通過網絡傳送到目標計算機磁盤。

 

• 前端網絡：服務器接受客戶端連接的網絡，也就是服務網絡，是服務器和客戶端連接的必經之路。

• 后端網絡：對客戶封閉，客戶的連接不用經過這個網絡，用與服務器和存儲、應用服務器、數據庫服務器的連接。可以是SAN，以太網

 

通過后端網絡備份

 

通過后端網絡備份的數據流向是：本地磁盤——總線——控制器——總線——內存——總線——后端HBA卡——線纜——后端交換設備——線纜——備份目的的后端網卡——總線——內存——磁盤。

 

LAN Free備份

 

　　備份的時候不經過LAN，也就是不流經前端網絡，也叫Frontend Free。這樣的好處是不耗費前端網絡的帶寬，對客戶終端接受服務器的數據不影響。

 

　　因為前端網絡一般是是慢速網絡 ，資源非常珍貴。無論是本地、還是網絡，都需要待備份的服務器付出代價，即需要讀取備份源數據到自身的內存，然后從內存寫入備份的目的地。對主機CPU、內存都有浪費。能否不消耗服務器的性能呢？可以，使用Server Free備份。

 

Server Free備份

 

　　Server Free備份的時候，數據不用流經服務器的總線和內存，消耗極少，甚至不消耗主機資源。備份源和備份目標都不會在服務器上，因為如果在服務器上，數據從磁盤讀出，要流將總線，然后到內存，這就不是Server Free？那怎么做呢？

 

• 用SCSI的擴展復制命令，將這些命令發送給支持Server Free的存儲設備，然后這些設備會提取自身的數據寫入備份目的設備，而不是發送給主機。

• 使用另一台專門做數據移動的新服務器，來代替原來服務器移動備份數據。釋放運算壓力很大的生產服務器。

 

備份引擎

備份引擎：決定整個數據備份系統應該怎么運作，備份那些內容，什么時候開始備份，備份時間有沒有限制等的策略。

 

備份服務器

 

　　備份引擎以什么形式體現呢？當然是運行在主機上的程序，所以需要一台計算機來做引擎的執行者。

 

　　那么備份服務器的備份策略和規則，怎么傳給整個數據備份系統中的服務器？通過以太網，因為以太網擴展性好，適合節點間通信。相對於以太網，SAN更適合傳送大量的數據。所以常用前端網絡來連接待備份的服務器和備份服務器，因為備份策略的數據包不多。

 

　　備份服務器如何與每個待備份的服務器建立通話？怎么通話？規則怎么定？需要待備份服務器上運行一個代理程序，專門解釋備份服務器發來的命令，根據命令作出動作。

 

　　這個運行在待備份服務器上的程序，就叫備份代理，監聽端口，接收備份服務器發來的命令。

 

介質服務器

 

　　若數據備份系統中有一台SCSI磁帶機，且多台主機想備份到這台磁帶機上。而SCSI磁帶機只能同時接到一台主機上。

 

　　那么怎么辦呢？可以引入一台專門的計算機，只能由這台計算機來操作磁帶機。

 

　　需要備份的計算機通過以太網將數據發給這台掌管磁帶機的計算機，然后寫給磁帶機。

 

　　這樣磁帶機成為了公用設備，而在整個系統中，只有一台計算機能掌管備份目標，它就類似於一個代理，代理其他服務器執行備份。我們把它稱為介質服務器。還有一個問題，如果有多台服務器向介質服務器發出請求，怎么辦?當然需要一個協調員，也就是備份服務器，它可以指揮安裝在待備份服務器的代理，讓每台服務器按照順序有條理的使用介質服務器提供的備份介質進行備份。

 

 

備份方式

完全備份

　　不管文件多大，只要要備份，都需要將文件都備份下來。

 

差量備份

　　只備份從上次完全備份以來發生變化的數據。差量備份要求必須做一次完全備份，作為差量的基准點

 

增量備份

　　只備份從上次備份以來這份文件中變化過的數據。不管是全備、差備，還是增量備份。

 

方案舉例

　　全備份+增量備份方案：假如我們周一做全備份，周二做增量備份是在周一的基礎上做的，周三做增量備份是在周二基礎上的，后面的類推。。。

　　全備份+差量備份方案：周一做全備份，周二做的差量備份是在周一的基礎上做的，周三的差量備份是在周一的基礎上做的，后面的類推。。。

 

方案比較：

　　全備份+增量備份，恢復的時候比較麻煩（需要依次恢復之前的每次增量備份直到全備份，比如說，恢復周四的備份，需要依次恢復周四的增量備份，周三的增量備份，周二的增量備份，周一的全備份），但節約空間；

　　全備份+差量備份，恢復的時候比較方便（只需恢復當天的差量備份和周一的全備份），占空間稍大。

 

　　對於數據庫的備份，備份軟件想知道每個數據文件的變化是不可能的，因為數據庫文件內部格式非常復雜，只有自己才能分析和檢測出來。所以數據庫管理軟件有自己的備份工具。第三方備份軟件只能調用數據庫軟件自身提供的命令。

 

總結