Why is the client showing high CPU utilization during deduplication backups?
How Do I Setup Deduplication for NAS NDMP Backups?
How to Deduplicate Microsoft SQL logs?
Can I Host DDB on Laptops or Workstations?
Deduplication Database (DDB) Backup Using Subclient
How Does Deduplication Database Backup Work?
What happens if VSS Snap fails during Deduplication Database (DDB) backup?
How to resize COW space size for snapshot creation?
Can I Schedule Deduplication Database Subclient Backups Using Other Backup Types?
What do I do when Deduplication Databases backup using DDB Subclient Fails?
Deduplication Database Recovery
What do I do when drive hosting the DDB is lost or the DDB files are missing?
How to continue my client backups during DDB recovery?
During backups, if client shows high CPU utilization then check the following:
The CPU Utilization on the client computers can be reduced by moving the data compression settings to the MediaAgent.
By default, the subclient properties have Use Storage Policy Settings option selected for compression. This means that if compression is enabled/disabled on the storage policy copy, then the subclient will follow this setting. Also, by default all deduplication storage policies will have client compression enabled. If you wish to override this behavior and perform compression on MediaAgent, then select On MediaAgent option on the subclient properties. See Modify Data Compression on Specific Subclient for step-by-step instructions.
For source side deduplication, if you have software compression option enabled on the storage policy copy, the compression will always happen on the client, except when the subclient property has compression set to Off. See Setting Up Data Compression for more information. |
Deduplication of NDMP data is supported for NetApp and EMC Celerra storage arrays to disk libraries attached to a CommVault Deduplication MediaAgent. When backing up to disk libraries attached to the MediaAgent, the NDMP backup data will traverse the network and be written and deduplicated to the disk library.
For all other NDMP vendors, Deduplication is supported but the savings may not be as high. To achieve higher Deduplication savings of these backups, it is recommended to move backups from NDMP to a mounted file system backup using the data residing on CIFS or NFS mount using the File System iDataAgent. However, before moving to CIFS or NFS file systems, make sure to verify the data transfer rate over CIFS or NFS as low transfer rate may result in slower backups. This configuration also supports Synthetic Full backups and DASH Copy.
Log Backups and Database Backups must be associated with different storage policies as follows:
No. If you have MediaAgent installed on Laptop or Workstation, hosting Deduplication Database on these machines is not supported.
Using the File System Agent is a preferred method for a deduplication database backup. This method allows the periodic backup of the deduplication database without requiring jobs to pause. This is done as follows:
Unix platform also support Extended 3 File System (ext3), and VERITAS Volume Manager (VxVM) file systems.
If you have configured LVM volumes, ensure
that enough disk space is available to accommodate LVM snapshots.
It is recommended that you have atleast 15% of unallocated space
on the volume group. Also, make sure that the amount of COW space to reserve while creating snapshots is atleast set to 10% of the Logical Volume size. See How to resize COW space size for snapshot creation? for step-by-step instructions. |
This method backs up all active (non-sealed) deduplication databases available in that MediaAgent.
To set up the deduplication database backup using file system, see Backing Up Deduplication Store Database.
During DDB backup using DDB subclient, if VSS snapshot fails, then the DDB backup will use Live Volume to back up the deduplication database. During this process:
During DDB backup, the COW (Copy-on-Write) space to reserve while creating snapshot of DDB must be atleast set to 10% of the Logical Volume size to avoid snapshot failures. Use the following steps to create nSnapCowSizeMB registry key to modify the COW space.
|
![]() |
No, you cannot schedule deduplication database subclient backup using other backup types. Deduplication database backup using subclient supports only FULL backup. Other backup types such as incremental, differential, synthetic full backups are not supported.
During deduplication databases backup using DDB subclient, if one of the deduplication database or the path is not available, backup job will fail with the following message:
Failed to Quiesce SIDB stores
To backup other deduplication databases successfully, select Failover to New Store option for a deduplication database which was not available during backup and then run the deduplication database backup.
If the drive (e.g., E:\) hosting the DDB is lost or the DDB files are missing, then reconstruct the DDB by performing the following the steps.
Use this procedure, if you configured deduplication database backup using file system DDB subclient. For more information, see Backing up Deduplication Store Database. |
qlogin -cs <commserve_name> -u <user_name>
qoperation execscript -sn <script_name> -si <database_store_id>
qoperation execscript -sn MarkStoreCorrupt -si 10
<script_name> - is the name of the script to be executed. Here the script name is MarkStoreCorrupt. Contact your Software provider to obtain this SQL script.
<database_store_id> - is the SIDBStoreID of existing deduplication database store. This ID can be obtained by running SQL query for IDxSIDBStore table in the SQL Management Studio.
From the Command Prompt, navigate to <Software_Installation_Directory>/Base and run the following command:
idxlabelutil.exe -op updateicl -ict 2 -srcapid <access_path_id> -apathid <access_path_id> -cn <client_name> -vm <instanceXXX>
idxlabelutil.exe -op updateicl -ict 2 -srcapid 123 -apathid 123 -cn client1 -vm instance001
apathid & srcapid - Access Path Id can be obtained by running the SQL Query for dbo.IdxSIDBStore table in the SQL Management Studio.
When you have multiple client backups scheduled to storage policy copy with deduplication and if the backup jobs are in a Waiting state for a long period of time due to the following reason (displayed in the Job Controller):
Library [lib4], MediaAgent [matador4], Drive Pool [DrivePool(matador4)271], Media[0]: The active SIDB Store of current storage policy copy is offline. DeDupe DB Reconstruction job will reconstruct the DB.
You can avoid the Waiting state of the backup jobs by enabling Allow backup jobs to run to deduplication storage policy copy when DDB being reconstructed option and temporarily disabling deduplication on the storage policy copy. This will allow to continue client backups to same deduplicated storage policy without deduplication. Note that once the reconstruction of DDB is completed, you must enable deduplication on the storage policy to continue the backups with deduplication.
Use the following steps to configure the client backups to continue during DDB recovery:
Use the following steps to disable the deduplication on storage policy copy: