DDB verification job performance - Verification of Existing Jobs on Disk and Deduplication Database

@drPhil , DDB verification jobs can definitely take a long time. 

The best way to look at this process is to take a step back and think about how Deduplication works:

A backup runs and stores data in 3 places: 1) The CS database knows what jobs run and what archive files (on the library) they are made up of.  2) the Dedupe Database knows which archive files/blocks exist and how many jobs reference them and 3) the library itself has the archive files (the actual formatted data blocks)

What the DDB verification operation does it look at the 3 of these areas and make sure they all match.  What blocks does the CS database think these jobs will need?  Are they on the library or not?

Now we can re-read this line from the docs:

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.

This is saying that we are cross referencing item 3 against what 1 and 2 expect to be there.  This way you don’t get caught flat footed if you go to restore data that is actually missing.  How does it do this?  We check the next line:

The jobs containing invalid data blocks are marked with the Failed status. These invalid unique data blocks will not be referenced by the subsequent jobs. As a result, new baseline data for the invalid unique data blocks is written to the storage media.

This way, the next time a job runs (that references these missing blocks), we write them back down.

As you can imagine, that is a LOT of work to check and it will take a LONG time.  there are some notes in that link about adjusting stream counts that might help.

Let me know if this helps!