Here’s the official line on what a DDB DV does:
Deduplicated Data Verification cross-verifies the unique data blocks on disk with the information contained in the DDB and the CommServe database. Verifying deduplicated data ensures that all jobs that are written as unique data blocks to the storage media are valid for restore or Auxiliary Copy operations.
The first time you run it will always be a Full, but you can do Incrementals afterwards:
Run Incremental Verification
Use this option to verify the deduplicated data blocks that are newly added or data blocks that are not verified during the last data verification job.
The slowness is generally due to slow read speeds on the disks (much of the time, RAIDs are set to favor write speeds).
The options are detailed here:
https://documentation.commvault.com/2022e/expert/12398_data_verification_online_help.html
The Quick version differences are here. you can see why Quick is much shorter because it does not read the data blocks, it only ensures the ddb and blocks are met. However, the point of a DV here is to make sure the blocks are actually valid, so you should skip the Quick version. Just run the Full the one time (it will definitely take a while) and do Incrementals going forward.
This should be the schedule defaults already.
| Options | When to use | Applies To |
|---|
| Quick verification of existing jobs on disk and deduplication database | Use this option for a quick verification of all the deduplicated jobs (unique data blocks and all references to the blocks) on the disk with the DDB and on the CommServe database. This option validates if the existing backup jobs are valid for restores and can be copied during Auxiliary Copy operations. In comparison with the Verification of existing jobs on disk and deduplication database option, this option is faster because it does not read the data blocks on the disk. Instead, it ensures that both the DDB and disk are in sync. | Full and Incremental Data Verification Job |
| Verification of existing jobs on disk and deduplication database | Use this option if you want to verify all existing backups and to ensure that the new backups refer only to valid data blocks. This option validates if the existing backup jobs are valid for restores and can be copied during Auxiliary Copy operations. | Full and Incremental Data Verification Job |
@Mike Struening
Thank you for the reply .
What impact running DDB Data verification for 10-20 days will cause on my backups and recovery jobs ?
I don't want my backups and recovery to get impacted or get slower due to this DV .
Also , how can i schedule data verification for non-dedupe storage policies . I see option to enable Data verification on storage policy copy advanced tab but didn't find any way to create a schedule for data verification of non-dedupe storage policy .
Your backups likely will be slower, depending on your resources.
DV uses 50 streams at the most but key thing is, pruning is disabled while the DV2 job is in the Job Controller (either running or pending/suspended) so if its going to run for a long time it can cause space issues.
Here’s the general DV documentation for non Dedupe:
https://documentation.commvault.com/2022e/expert/12372_getting_started_with_data_verification.html
If your verification jobs take 30 days, then you have an environmental performance issue that should probably be resolved. Even if your current backups run quickly and complete within SLA, your restores may not be able to meet RTO. This is because with Commvault deduplication, backup jobs have very little work to do since workloads are distributed across clients and there is client side dedupe enabled by default for all jobs. Compare that to restores though when you have to read every block required, that would be very similar to a verification.
I guess since my DDB application size is in PBs ( 3-5 PBs) that's why its is showing 10-20 days for first full verification.
If you’ve never verified, then yes, you should probably invest that time to at least do 1 full verification to make sure data is actually restorable.
I agree with Jordan, in order to verify your current data and actively maintain correct relations between DDB and data blocks I would recommend to invest for the solution in the long run and thus perform a full verification. The following quick verifications will take a fraction of the time needed for the full job.
But.. it all stands or falls with your environments capacity, if the DDB verification blocks your ability to meet RPO/RTO requirements then you might need to reconsider, but this is a decision based on business requirements and not a technical consideration.
