During backups, if client shows high CPU utilization then check the following:
Data Compression settings and Signature Generation on the subclient
Data Compression settings on the Storage Policy being used
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.
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:
Installing File System iDataAgent as a Restore Only Agent (which does not
consume license) on the MediaAgent hosting the deduplication database.
Configuring the file system subclient by selecting DDB Subclient
option. This will automatically define the deduplication databases as the subclient
content.
Scheduling the deduplication database backup job as frequently as desired
for database protection.
When the deduplication database backup job is initiated:
All communication to the active deduplication database is paused for
a few seconds. The information in memory is committed to disk to ensure
the deduplication database is in a quiesced state.
It quickly creates a snapshot of the volume using VSS (Windows) / LVM
(Unix) snapshots.
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.
Once the snapshot is created, all the communication to the deduplication
database is resumed and it automatically backs up the deduplication database
from that snapshot.
After a deduplication database has been backed up successfully, the snapshot
is deleted. Throughout this time, the Job Controller will show the jobs in a
running state.
This method backs up all active (non-sealed) deduplication databases available
in that MediaAgent.
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:
The DDB backup will be in quiesced state and may take longer time than expected
to finish the backup job.
If there are any regular backup jobs running during this period, then those
jobs may get affected.
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.
From the CommCell Browser, navigate to Client Computers.
Right-click the <DDB MediaAgent Linux Client> in which
you want to add the registry key, and then click Properties.
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.
<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.
Manually reconstruct the new deduplication store. See
Manually Reconstruct a Store
for step-by-step instructions.
After reconstruction, run the idxlabelUtitool tool to generate the
icl_label.txt file.
From the Command Prompt,
navigate to <Software_Installation_Directory>/Base
and run the following command:
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:
From the CommCell Browser, from the ribbon click Storage
tab.
Click the Media Management icon.
From the Media Management Configuration dialog box, click
Resource Manager Configuration tab.
By default, Allow jobs to run to dedup copy when DDB being reconstruction
value is set to 0 (OFF).
To enable, set the value as 1.
Click OK.
Use the following steps to disable the deduplication on storage policy copy:
From the CommCell Browser, navigate to Policies | Storage Policy
| <Storage Policy>
Right-click the <Deduplication Storage Policy Copy>
and then click Properties.
Click the Deduplication tab and then click the Advanced
Options tab.
Clear Active check box to temporarily disable the deduplication.
Click OK.
Note that after DDB reconstruction, repeat above
steps by selecting Active check box to enable deduplication.
