Hi @BillK , thanks for the post and welcome!
this is definitely an interesting topic. the question is answered (high level) here:
https://documentation.commvault.com/2022e/expert/12514_deduplication_database_recovery.html
When the deduplication database (DDB) or partition of the DDB is detected as offline, unreadable, or unavailable, the DDB is automatically recovered from the latest DDB backup. This is the default recovery setting.
Note: While running the DDB reconstruction job, if the restored DDB is found invalid or corrupted, then both the Last DDB Backup Job Id and the Last DDB Backup Time stamp are reset. You must run a full reconstruction process that deletes the existing DDB content, reads the entire data on the disk, and re-creates a new DDB from the deduplicated data read on the disk.
DDB recovery process performs the following activities:
-
Adds new records in the restored DDB for all the backups that were added to the DDB between the backup and when they went offline.
-
Ensures that the data in the DDB and the CommServe database are in sync by cross-verifying and updating the metadata with the CommServe database with the DDB.
-
Ensures that the DDB has been successfully reconstructed.
The first two items of importance are that the first step is to restore the latest DDB backup. In almost certain likelihood, there will be jobs that have run and completed since this DDB backup happened, so how do we restore the DDB to its TRUE most recent state?
The recon process looks at the data on the disk and reads the meta data files (aka the files about the files), then compares that to the Commserve database to see what is not in sync.
For that to make sense, it’s best to think about what information lives where:
- The Commserve database knows about each job and which archive files each job ‘needs’
- The Dedupe Database knows how many references exist per archive file/block
Now, if the Recon process sees that there are a different number of references in the currently-in-recon-ddb than it should have, then it adjusts the DDB accordingly. Same for any new chunks/archive files.
This does take a decent amount of time, though if you don’t have a valid DDB backup and have to do a Full Recon then you can see how it would take even longer!
Let me know if that helps explain everything.
I’m still a bit confused. Is the storage library (The actual backup data) consulted as part of the reconstruction process? Thanks you.
That’s correct. The metadata utilized is within the Chunk folders on the actual storage.
above scenario apply for disk failure where DDB is store as well? Thank you