CommVault去重DDB相關的幾個問題

標籤：commvault   ddb   去重庫   

通過自身對CommVault備份的接觸及相關學習，現就其DDB去重庫的問題進行整理：

1. ddb是存放在什麼位置？ 源端去重的ddb Cache跟真正的ddb的區別是什麼

2. DASH copy是怎麼工作的？ DASH copy的過程中，網路最佳化方式和讀取最佳化方式區別是什麼

3. DASH FULL是怎麼工作的？

4. DDB是怎麼保護的？有幾種保護方式，如果出現問題應該怎麼辦？

5. DDB在資料老化到期過程中起到什麼樣的作用？

6. 如果CommServe DB重新恢複後，DDB有什麼影響？

7. 如果DDB壞了，對恢複有沒有影響？

8. 如果DDB被人為刪除了，這種操作允許嗎？建不建議使用者人為刪除DDB?
9. 封存後的DDB，還有什麼用途？
10. 當一個DDB被封存後，產生一個新的DDB，那麼以後的備份資料產生的簽名就會直接寫到這個新的DDB中，那封存後的DDB中的簽名有可能同步到新的DDB中嗎？

1. ddb是存放在什麼位置？ 源端去重的ddb Cache跟真正的ddb的區別是什麼
   
   DDB是CommVault去重功能中用於存放資料在切片時產生的簽名的各種索引資訊，同時還存放了這些相同簽名所對應的資料區塊的資訊。當啟用了去重的功能後，在備份資料來源那端會將檔案或者資料庫等產生兩種資訊，即檔案的簽名和相應的Segment，也就是資料區塊。
   1). 首先將簽名送到DDB中進行對比，如果發現簽名資訊已經在DDB中存在，就直接更新DDB, 將DDB中的這個簽名的記錄加1，即更新指標後，不傳送Segment或者資料區塊。
   2). 當發現DDB中的簽名不存在，那就在更新DDB的同時，將相應的資料區塊送到DDB所關聯的儲存策略的相應Copy中；
   3). 如果希望源端去重時，第一次對比的DDB是在用戶端，而不是直接到MA上去對比，就需要在用戶端那邊放一個DDB Cache, 這樣的話，資料在切片後產生的簽名和相應的Segment，就會優先去源端的DDB Cache中去對比，來初步判斷需不需要傳遞Segment.

   
   

2.  DASH copy是怎麼工作的？ DASH copy的過程中，網路最佳化方式和讀取最佳化方式區別是什麼
   
   DASH COPY簡單的講，就是在一個儲存策略中，主拷貝已經去重，如果想把去重後的資料傳送到二級拷貝中，那我們就可以把這種去重的Auxiliary Copy叫做DASH Copy; 這樣方案往往用在遠程容災的方案中較多。
   那既然可以將去重後的資料傳送到次級拷貝中，那是如何?將去重後的資料送到次級拷貝中呢？簡單地講，就是在次級拷貝中，也會有一個DDB,用於管理次級拷貝中的去重資料資訊，把第一級拷貝中的資料的簽名和資料區塊產生後，先將簽名送到二次拷貝的DDB中去對比，如果簽名已經存在，那就不用再傳資料區塊，只需要更新DDB中的簽名資訊以及對應的資料區塊指標即可。那麼，具體的簽名和資料區塊是怎麼傳到二級拷貝中的呢？這就涉及到了讀取最佳化和網路最佳化的兩種傳遞方式了，請參考：
   650) this.width=650;" id="aimg_91" src="http://scs.commvault.com/data/attachment/forum/201202/28/094546ufpa7earkamqqpfl.jpg" class="zoom" width="577" alt="094546ufpa7earkamqqpfl.jpg" />
   
   在DASH Copy的傳送過程中，可以有兩種傳送方式：
   a).  網路最佳化方式：
   中，網路最佳化方式中，在source copy中找到需要運行aux copy的作業資訊，將這些作業資訊資料解開後，重新得到簽名和相應的資料區塊(Segment）資訊，先和Source Copy中所對應的DDB進行對比。
         如果Source Copy中的DDB庫中已經含有相應的簽名，則只更新Source Copy中的簽名表，再繼續和Target Copy中的DDB進行對比，如果Target Copy中的DDB中也已經含有相應的簽名，則只更新Target copy中的DDB表資訊，不傳送資料區塊。
          如果Source Copy中的DDB庫中已經含有相應的簽名，則只更新Source Copy中的簽名表，再繼續和Target Copy中的DDB進行對比，如果Target Copy中的DDB中沒有含有相應的簽名，則需要在更新Target copy中的DDB表資訊的之後傳送資料區塊。
          如果Source Copy中的DDB庫中沒有相應的簽名，則需要更新Source Copy中的簽名表，再繼續和Target Copy中的DDB進行對比，如果Target Copy中的DDB中已經含有相應的簽名，則只更新Target copy中的DDB表資訊，不傳送資料區塊。
        如果Source Copy中的DDB庫中沒有相應的簽名，則需要更新Source Copy中的簽名表，再繼續和Target Copy中的DDB進行對比，如果Target Copy中的DDB中沒有含有相應的簽名，則需要在更新Target copy中的DDB表資訊的之後傳送資料區塊。
   
   b). 讀化化方式：
   中，讀取最佳化方式中，在source copy中找到需要運行aux copy的作業資訊，直接讀取這些作業所對應的CHUNK資訊，從而得到簽名和相應的資料區塊(Segment）資訊，直接和Target Copy中的DDB進行對比，從而來判斷是否需要傳送相應的資料區塊。
   
          從CHUNK的metadata資訊中直接找到需要傳送作業的簽名資訊和對應的資料區塊資訊，先把簽名和Target Copy中的DDB進行對比，如果Target Copy中的DDB中也已經含有相應的簽名，則只更新Target copy中的DDB表資訊，不傳送資料區塊。
   
         從CHUNK的metadata資訊中直接找到需要傳送作業的簽名資訊和對應的資料區塊資訊，先把簽名和Target Copy中的DDB進行對比，如果Target Copy中的DDB中也沒有相應的簽名，則在更新Target copy中的DDB表資訊後傳送對應資料區塊。
   

   
   

3.  DASH FULL是怎麼工作的？
   
   在講述了DASH COPY中，知道了DASH COPY是指兩個Copy之間傳送去重後的資料，那DASH FULL的原理就好理解了，簡而言之，DASH FULL就是指在一個Copy之間的去重。這個就是指在運行合成全備份時，不需要將原來變化後的增量資料和上一份的全備份重新打包產生一個新的全備份資料（這裡不是指不用產生新的全備份），而是在新的全備份中，在DDB中標記去重後的資料區塊指標，這樣的話，新的合成全備份的資料量就會很小。
   在沒有使用DASH FULL的情況下，合成全備份會將上次的全備份和最後變化的增量合成打包成一個新的全備份。
   

   
   

4.  DDB是怎麼保護的？有幾種保護方式，如果出現問題應該怎麼辦？
   
   上面講述了在去重的過程中，都需要及時地與DDB打交道，從而來判斷要不要進行去重等，那DDB本身出問題，影響是什嗎？是不是資料就不去重了？如何對當前的DDB進行保護？
   
   在規劃方案時，需要注意DDB一定要放在一個高速的硬碟上，具體的要求請參考BOL介紹的Deduplication Building Block Guide
   
   http://documentation.commvault.com/commvault/release_9_0_0/books_online_1/english_us/prod_info/dedup_disk.htm?var1=http://documentation.commvault.com/commvault/release_9_0_0/books_online_1/english_us/features/dedup_disk/building_block.htm
   
   那麼具體的保護原則有兩種，可以根據實際情況選擇：
   a). 在儲存策略上設定，如果DDB出現問題時，可以直接切換至新的DDB; 或者回退到上一個DDB的快照點。可以根據實際情況設定。
   b). 建立一個DDB備份的子客戶端，定製計劃定期備份DDB;
   
   具體請參考 http://documentation.commvault.com/commvault/release_9_0_0/books_online_1/english_us/prod_info/dedup_disk.htm?var1=http://documentation.commvault.com/commvault/release_9_0_0/books_online_1/english_us/features/dedup_disk/advanced.htm#Deduplication_Store_Database
   

   
   

5.  DDB在資料老化到期過程中起到什麼樣的作用？
   
   在前面我們介紹了DDB中包括了簽名的資訊，以及每個資料區塊所對應的簽名記數器或者說指標，那麼在資料老化(Data Aging）的過程中，就需要和DDB進行通迅，來確認簽名的記數器是不是已經為0，從而來判斷這個資料區塊是不是可以從磁碟庫上來刪除，所以請不要人為地刪除DDB相關的資訊。否則可能會導致部分作業資訊由於在資料老化的過程中，無法與DDB通迅從而不到期這些本應到期的作業。
   
   

6.  如果CommServe DB重新恢複後，DDB有什麼影響？
   
   由於DDB中記錄的作業資訊不能比CommServe DB中的記錄資訊新，所以在CommServe DB恢複到之前的時間點時，需要確保對最新的DDB進行封存，或者回退到之前的某個DDB的時間點。從而保證DDB和CommServe DB中的資訊一致。
   

   
   

7.  如果DDB壞了，對恢複有沒有影響？
   
   由於在磁碟庫的CHUNK的Metadata資訊中記錄了備份作業的各種簽名資訊，所以DDB損壞了，不影響原來備份資料的恢複。

   
   

8.  如果DDB被人為刪除了，這種操作允許嗎？建不建議使用者人為刪除DDB?
   
   強烈不要人為刪除DDB。 不要因為磁碟空間不足，去人為刪除DDB的目錄。可能因為人為刪除了DDB,導致資料老化的過程中，或者在去重的過程中，出現不能與DDB通迅的情況，出現資料不能到期或者去重的作業不能繼續啟動並執行情況。
   

   
   

9.  封存後的DDB，還有什麼用途？
   
   封存後的DDB,在資料老化的過程中，Data Aging這個進程會與DDB通訊，來判斷哪些作業可以到期。另外，如果使用了一些特別的選項，封存後的DDB，仍然是活動的，在去重的過程中，會繼續使用。
   

   
   

10.  當一個DDB被封存後，產生一個新的DDB，那麼以後的備份資料產生的簽名就會直接寫到這個新的DDB中，那封存後的DDB中的簽名有可能同步到新的DDB中嗎？
    
    可以採用priming option來同步，這種情況很少用。
    

本文出自 “亞顛之光” 部落格，謝絕轉載！

CommVault去重DDB相關的幾個問題