Skip to main content

Hi there,

 

I want to share my experience with DDB reconstruction. My colleagues started the DDB database reconstruction because the DDB database was not in good condition. There were no current backups of DDB database (the last backup was 14 days old) and maybe some other error messages were active. They decided to start full reconstruction, maybe there was no option to make manual backup of the DDB database - hm, but the database had not been updated with new records anyway. The thing is that the reconstruction is very time consuming and moreover, since the DDB database is not running the backup jobs are not possible. The workaround we did was to temporarily disable deduplication. Another caveat is that we are running out of disk space. And that is how a disaster looks like:grinning: .

 

At the end I wil put my hypothetic questions. Is the DDB database needed for restoring of data - I wouldnt say so. And what would happen if the broken DDB database was deleted and completely the new one was built from scratch?

Take care!

Quick answer, we do NOT need the DDB to restore.  It’s only used when writing new jobs (new records, etc.) and during pruning of jobs/files.

So what happens if it is gone or problematic?  Assuming no restore or reconstruction (which is your question), then we mark the store as corrupt, start a new DDB (for new jobs) and cease micro pruning (because we can’t decrement records since there’s no DDB).  We then will wait until ALL jobs in the store age off (remember, the Commserve Database knows which jobs belong to which Store IDs), then remove ALL of the blocks for that store in one big macro prune.

A slightly exaggerated 99% of all deduplication issues we see in support are due to not sizing/planning disk performance.

Luckily, we have a big huge guide for this, though it has to be considered before things get problematic:

https://documentation.commvault.com/commvault/v11/article?p=12410.htm

Reply


Terms & ConditionsCookie settings