1.快照用途

通俗法：快照的作用主要是能夠進行線上資料恢復，用資料庫採集下系統某一時刻的資料，將資料存入資料庫中，當儲存裝置發生應用故障或者檔案損壞時可以進行及時資料恢復，將資料恢復成快照產生時間點的狀態。快照的另一個作用是為儲存使用者提供了另外一個數據訪問通道，當原資料進行線上應用處理時，使用者可以訪問快照資料，還可以利用快照進行測試等工作。利用不同時間點的快照，還可以生成報告，用來檢測系統在這段時間的效能趨勢。

學術法：資料庫快照是資料庫（源資料庫）的只讀靜態檢視。在建立時，每個資料庫快照在事務上都與源資料庫一致。在建立資料庫快照時，源資料庫通常會有開啟的事務。在快照可以使用之前，開啟的事務會回滾以使資料庫快照在事務上取得一致。

2.快照分類

快照通常有六種型別：

（1）Copy-on-write 複製寫

（2）Redirect-on-write 重定向寫

（3）Clone or split mirror 克隆或映象

（4）Copy-on-write with background copy  後臺拷貝的複製寫

（5）Incremental 增量快照

（6）Continuous data protection 持續資料保護

複製寫和重定向寫快照

Copy-on-write（COW） 複製寫

COW快照需要消耗一些儲存空間建立快照卷。當我們為一個數據卷建立一個快照後，這些預留的空間用來存放而被變化資料更新的舊資料。COW快照在初始化的過程中僅僅建立用來描述源資料塊位置的指標資訊（元資料），而不是完整的將源資料拷貝過來。因為初始化的過程幾乎可以再瞬間完成，對系統的影響也很小。

COW快照會跟蹤資料卷的寫操作和資料塊的變化。當某個資料塊發生改變時，在將舊的資料覆蓋之前，首先將該塊的舊資料複製到預留的快照卷，該步驟僅在資料卷相應資料塊位置發生第一次寫操作請求時進行。這個處理過程確保快照出來的資料與發起快照的那個精確時間點保持完全一致。這個過程也描述了“copy on write”這個名字的含義。

如果我們需要訪問某個時間點的快照資料，對沒有改變過的塊直接從資料卷讀取；對已經改變並被複制的塊則從快照空間讀取。從快照被建立那一刻起，每個快照都會跟蹤記錄描述塊改變的元資料資訊。

COW快照的主要優勢在於空間的高效利用，因為快照卷只需要保留髮生過變化的資料塊，與資料卷相比要小得多。但是我們也知道COW快照有個缺點，它會引起資料卷效能的下降，這是因為建立快照之後，對資料卷的寫操作會增加一個等待的過程-即舊資料複製到快照卷的過程。另外一個關鍵問題是每個快照卷必須依賴一個完整的資料卷。

Redirect-on-write(ROW)重定向寫快照

“ROW重定向寫”與“COW複製寫”是相對的概念，它可以避免兩次寫操作引起的效能損失。ROW 同COW一樣在空間利用方面效率非常高。那是什麼讓ROW快照避免了寫效能的損耗？其中的原因是ROW把對資料卷的寫請求重定向給了快照預留的儲存空間，而寫操作的重定向設計則把需要兩次寫才能完成的操作減少為一次。我們知道COW的兩次寫包括：1.將舊資料寫入快照卷；2.在資料卷寫入新資料。而ROW只寫入新資料一步。

使用ROW快照，資料卷存放的是上一個快照時間點的舊資料，新資料最終存放在預留的快照空間。這裡也有一個複雜的問題，就是快照的刪除。被刪除的快照上的資料必須被複制到原始資料卷，並且做一致性回退。建立的快照越多，維護快照的複雜度也會以指數級別上升。這些複雜性包括對原始資料的訪問、快照資料和原始資料卷的跟蹤、以及快照刪除後的資料調整。另一個直接引發的嚴重問題是，原始資料集中會產生大量的碎片。

克隆或分割映象快照與後臺拷貝的複製寫快照技術

Clone or split-mirror 克隆或分割映象快照

Clone（或split-mirror）快照所建立的是資料的完整副本。Clone（或split-mirror）快照的物件可以是一個儲存卷、一個檔案系統或是一個Lun(logical  unit  number 邏輯單元號)。Clone快照的優點是它們具有高可用性；缺點是所有的資料都要完整的複製一份，複製的過程也不可能在瞬間完成。我們可以分割一對保持同步狀態的映象捲來啟用Clone快照，分割的過程瞬間即可完成。然而，當映象被分割成Clone快照之後，資料卷也就失去了他的同步映象。

使用Clone快照需要面對一個非常嚴重的問題是每個快照都需要和資料卷一樣大的儲存空間。尤其是當我們在任何時刻都需要保持一份以上Clone卷的情況，這個成本會非常高。另一個缺點是影響效能，因為在映象卷之間保持寫同步需要一定的系統開銷。

Copy-on-write with background copy 後臺拷貝的複製寫快照

copy-on-write with background copy快照有兩個生成步驟：首先建立一個瞬時即可生成的COW快照；然後利用後臺程序將資料卷的資料複製到快照空間，最後生成一份資料卷的克隆或映象。

建立這種快照的目的是發揮COW快照的優勢，同時儘量遮蔽它的不足。因此，這種快照常常被形容為COW和Clone快照的混合體。

增量快照與持續資料保護

（Incremental）增量快照

增量快照的特點是可以跟蹤資料卷和快照卷的變化。當一個新的增量快照生成之後，舊的快照資料將被重新整理。第一個快照和隨後建立的每一個增量快照資料上都有時間戳標記，利用時間戳我們能夠快照資料回滾到任意的一個時間點。增量快照技術能夠加速後續快照的生成速度，而且僅僅在名義上多消耗一點空間而已。因此，我們可以提高建立快照的頻率，也能讓快照保留的更久一點。

增量快照的不足之處是它需要依靠上面所提到的其它基礎技術來建立第一個快照(COW,ROW,clone/split mirror，copy-on-write with background copy)。如果用Clone方式，那麼第一個快照需要較長的初始化時間，如果用COW方式，資料卷的效能會降低。

持續資料保護（CDP）

CDP的出現是為了實現零資料丟失的RPO指標，以及瞬時資料恢復的RTO指標。它本身與同步資料映象很相似，不同之處在於CDP還可以對軟體災難進行恢復。包括認為誤操作、惡意軟體攻擊、意外刪除、資料損壞等情況。

持續資料保護頗像頻率很高的增量快照。它會捕獲並複製任何時刻發生的資料變化，並且給這些資料塊打上時間戳。CDP本質上相當於每個時刻都建立一份增量快照，提供細粒度的精確資料恢復。有些CDP產品同時提供基於時間和基於事件（例如應用程序升級事件）兩種粒度的恢復方式。還有一個理解CDP概念的好方法就是將它看成一個快照的journal日誌。

對於郵件系統、資料庫和基於資料庫的應用來說，CDP是一個極好的保護方案，能將資料回滾到任意的歷史時間點，恢復過程也簡便、迅速。最有代表性的CDP產品是飛康公司的IPStor，它是一個集成了CDP功能的儲存系統兼儲存虛擬化裝置。

隨著越來越多的資料需要保護，備份視窗也變得越來越緊張，因此需要快照技術來幫助我們解決備份問題。在現實的應用環境中，快照利用的是否恰當對資料保護的等級和恢復的速度有著很大的影響。儘管各型別快照之間存在的技術差異並不太容易理解，但無論如何，快照技術都將在資料保護領域和日常儲存管理中扮演重要的角色。

特別注意：快照的一致性問題

如果用快照來處理結構化資料，可能會存在一些問題。結構化資料涉及到資料庫，以及資料庫類的應用（例如郵件系統、ERP或CRM等等）。許多產品中的快照並不能與這些應用程式整合或被直接呼叫。有一種可能的情況是，在我們建立快照的瞬間，資料庫恰好不在靜止狀態（快取正在重新整理、寫操作事務尚未完成、索引和元資料正在更新等等），此刻生成的資料快照是不一致的，很有可能無法正常使用。

在微軟的Windows Server平臺上，這個問題要簡單的多，利用windows Volume Shadow Copy Services(VSS)和它的API，資料庫應用程式可以整合並呼叫快照工具。VSS是專門為結構化資料應用設計的服務礦建，可以驅動資料庫等應用進入資料一致性的靜止狀態，在快照開始初始化之前，完成重新整理快取、結束寫操作以及系統狀態的更新。

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

這裡還有一個好辦法，可以不通過windows VSS，獲得資料庫的一致性快照。這個辦法需要備份軟體的配合。將快照技術的API同備份軟體整合，就可以從備份伺服器端驅動備份軟體的資料庫代理Agent。Agent備份代理程式可以驅動資料庫進入靜止狀態，然後反向讓備份伺服器通知快照工具開始執行建立快照的操作。這也是一個比較有效的辦法。

3.GFS的snapshot

GFS的snapshot採用的是寫時複製的機制進行的，COW，GFS快照操作幾乎可以瞬間完成對一個檔案或者目錄樹（“源“）做一個拷貝，並且幾乎不會對正在進行的其它操作造成干擾。我們的使用者可以使用快照迅速的建立一個巨大的資料集的分支拷貝（而且經常是遞迴的拷貝），或者是在做實驗的資料操作之前，使用快照操作作備份當前狀態，這樣之後就可以輕鬆的提交或者回滾到備份時的狀態。

參考：

http://www.db110.com/%E8%BD%AC-%E4%B8%8D%E5%90%8C%E7%B1%BB%E5%9E%8B%E7%9A%84%E5%BF%AB%E7%85%A7%E5%8F%8A%E5%B7%A5%E4%BD%9C%E5%8E%9F%E7%90%86/

http://blog.csdn.net/yuanrxdu/article/details/22887965