CommVault去重DDB相关的几个问题

Posted 2020-08-25

通过自身对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中的签名信息以及对应的数据块指针即可。那么，具体的签名和数据块是怎么传到二级拷贝中的呢？这就涉及到了读优化和网络优化的两种传递方式了，请参考下图：
   
   
   在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来同步，这种情况很少用。
    

本文出自 “亚颠之光” 博客，谢绝转载！