CommVault go to heavy DDB related issues

Through its own contact with the backup of CommVault and related learning, it is now the DDB to re-library issues to organize:

1. Where is DDB stored? What is the difference between the source-heavy DDB cache and the real DDB?

2. How does DASH copy work? What is the difference between the network optimization mode and the Read optimization method in the DASH copy process?

3. How does DASH full work?

4. How is DDB protected? There are several ways to protect, what should I do if there are problems?

5. What role does DDB play in the expiration of data aging process?

6. What is the effect of DDB if CommServe db is restored?

7. If the DDB is broken, does it have any effect on recovery?

8. If DDB has been artificially removed, does this permit? Is it not recommended for users to manually delete DDB?
9. What is the use of the DDB after storage?
10. When a DDB is sealed and a new DDB is created, then the signature generated by subsequent backup data is written directly to the new DDB, and will the signatures in the archived DDB be synced to the new DDB?

2. Where is DDB stored? What is the difference between the source-heavy DDB cache and the real DDB?
   
   DDB is a variety of index information used in CommVault's deduplication function to hold the signature generated by the data during slicing, as well as the data blocks that correspond to the same signature. When the deduplication function is activated, the backup data source will generate two kinds of information such as file or database, that is, the file's signature and the corresponding segment, which is the data block.
   1). First the signature sent to the DDB for comparison, if found that the signature information already exists in DDB, directly update DDB, the DDB in the signature of the record plus 1, that is, after updating the pointer, do not transfer segment or data block.
   2). When a signature in the DDB is found to be absent, the corresponding data block is sent to the corresponding copy of DDB's associated storage policy while the DDB is being updated;
   3). If you want the source to go heavy, the first comparison of the DDB is in the client, rather than directly to the MA to compare, you need to put a DDB cache on the client side, so that the data after slicing the resulting signature and corresponding segment, will first go to the source side of the DDB cache to compare , to make a preliminary judgment need not pass segment.

   
   

3. How does DASH copy work? What is the difference between the network optimization mode and the Read optimization method in the DASH copy process?
   
   DASH copy simply says that in a storage strategy, the primary copy has gone heavy, if you want to send the deduplication data to a level two copy, then we can call this deduplication auxiliary copy called Dash copy; Such schemes are often used in remote disaster-tolerant scenarios.
   So now that the deduplication data can be transferred to the secondary copy, how is it possible to send the deduplication data to the secondary copy? Simply put, in the secondary copy, there will also be a DDB, used to manage the deduplication data in the secondary copy, the first level copy of the data in the signature and data block generation, the signature is sent to two copies of the DDB to compare, if the signature already exists, then no more data block, You only need to update the signature information in the DDB and the corresponding data block pointers. So, how are specific signatures and data blocks uploaded to a level two copy? This involves two modes of transmission for read optimization and network optimization, please refer to:
   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 "/>
   
   There are two ways to transfer the dash copy during the transfer process:
   a). Network optimization mode:
   , in the network optimization mode, the job information that needs to run aux copy is found in source copy, and after the data is unpacked, the signature and the corresponding data block (Segment) information are re-compared with the DDB corresponding to source copy.
   If the DDB library in source copy already contains the corresponding signature, update only the signature table in source copy, and then continue to compare with the DDB in target copy, if the DDB in target copy already contains the corresponding signature. Updates the DDB table information in target copy only, without transmitting the data block.
   If the DDB library in source copy already contains the corresponding signature, update only the signature table in source copy, and then continue to compare with the DDB in target copy if the DDB in target copy does not contain the corresponding signature. You need to pass the data block after updating the DDB table information in target copy.
   If there is no corresponding signature in the DDB library in source copy, you need to update the signature table in source copy, and then continue to compare it with the DDB in target copy, if the DDB in target copy already contains the corresponding signature, update only the target The DDB table information in copy does not transmit data blocks.
   If there is no corresponding signature in the DDB library in source copy, you need to update the signature table in source copy, and then continue to compare it with the DDB in target copy, if the DDB in target copy does not contain the corresponding signature. You need to pass the data block after updating the DDB table information in target copy.
   
   b). The way of reading:
   , in the read-optimized mode, the job information that needs to run aux copy is found in source copy, and the chunk information corresponding to these jobs is read directly to obtain the signature and corresponding data block (Segment) information, which is directly compared with the DDB in target copy. To determine if the corresponding data blocks need to be transmitted.
   
   From the metadata information of chunk, we can find the signature information and corresponding data block information of the transfer job directly, compare the signature with DDB in target copy, and if the DDB in target copy already contains the corresponding signature, only update the target The DDB table information in copy does not transmit data blocks.
   
   From the metadata information of chunk, we can find the signature information and corresponding data block information that need to transfer job directly, compare the signature with DDB in target copy, and if there is no corresponding signature in the DDB in target copy, update the target Copy the DDB table information and then transfer the corresponding data block.
   

   
   

5. How does DASH full work?
   
   When it comes to dash copy, knowing that dash copy is a data transfer between two copy, the dash full principle is understandable, in short, dash full refers to the deduplication between a copy. This means that when you run a synthetic full backup, you do not need to repackage the original changed incremental data and the previous copy of the full backup to generate a new full backup data (this does not mean not to generate a new full backup), but in the new full backup, in the DDB to mark the deduplication block pointer, so that, The amount of data for the new synthetic full backup will be small.
   In the absence of the dash full, synthetic all backups package the last full backup and last-changed incremental compositions into a new full backup.
   

   
   

6. How is the

7.  ddb protected? There are several ways to protect, what should I do if there are problems?
   
   described above in the process of weight, all need to deal with DDB in a timely manner, so as to determine whether to go to the weight, the DDB itself problem, what is the impact? Isn't the data going to be heavy? How to protect the current DDB?
   
   In planning scenarios, it is important to note that DDB must be placed on a high-speed hard drive, please refer to the 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
   
   There are two specific protection strategies, which can be selected according to the actual situation:
   a). Set on the storage policy, you can switch directly to the new DDB if there is a problem with DDB, or fall back to the previous DDB snapshot point. Can be set according to the actual situation.
   B). Create a DDB backup sub-client, custom plan to regularly back up DDB;
   
   For details, refer to 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
   

   
   

9. What role does DDB play in the aging of data?
   
   In the previous section, we introduced the signature information in DDB, as well as the signature register or pointer for each block of data, so in the process of data Aging, we need to communicate with DDB to confirm that the signature register is already 0. In order to determine whether the data block can be deleted from the disk library, please do not artificially delete DDB related information. Failure to do so may result in some job information being unable to expire with DDB in the course of data aging.
   
   

11. What is the effect of DDB if CommServe db is restored?
    
    Because the job information recorded in the DDB cannot be newer than the record information in CommServe DB, it is necessary to ensure that the latest DDB is sealed or rolled back to a previous DDB point in time when CommServe DB recovers to a previous point in time. This ensures that the information in DDB and CommServe DB is consistent.
    

    
    

13. If the DDB is broken, does it have any effect on recovery?
    
    Because the various signature information of the backup job is recorded in the chunk metadata information of the disk library, DDB is corrupted and does not affect the recovery of the original backup data.

    
    

15. If DDB has been artificially removed, does this allow? Is it not recommended for users to manually delete DDB?
    
    It is strongly not to remove DDB artificially. Do not manually remove the DDB directory because of insufficient disk space. May be due to the human removal of DDB, resulting in the process of data aging, or in the process of de-duplication, there is a situation that can not be linked to the DDB, the data can not expire or go to heavy jobs can not continue to run.
    

    
    

17. What's the use of the DDB after it's been sealed?
    
    After the storage of DDB, the data aging process will communicate with DDB to determine which jobs can expire during the aging process. In addition, if some special options are used, the post-sealed DDB is still active and will continue to be used in the process of de-emphasis.
    

    
    

19. When a DDB is sealed and a new DDB is created, then the signature generated by subsequent backup data is written directly to the new DDB, and will the signatures in the archived DDB be synced to the new DDB?
    
    It can be synchronized using priming option, which is rarely used.
    

This article from "The Light of Asia" blog, declined reprint!

CommVault go to heavy DDB related issues