A DDB Rsync runs in the background daily as a scheduled process. The DDB will be online and useable, but you will see the icon until it runs.
The Commserve and DDB are responsible for keeping track of the data being written. When a situation like a disaster recovery operation of the CommServe could potentially cause an out of sync situation especially if the CommServe Database was from an earlier point in time after new data has been written to the library. Other offline condition can lead to the tables between the CommServe and DDB to be out of sync. In these scenarios a resynchronization of the Deduplication Database must occur. The resynchronization process will validate and update the tables of the new archive files and pruge any archive files that are invalid such as aged data from the time of the restoration of the commserve Database.
When an inconsistency with synchronization is detected, the DDB’s are placed in maintenance mode and an automated process is run to being synchronizing. During this time no protection operations and or pruning can occur until the resynchronization is complete. This process uses the same logic and logging as Validation and pruning operation.
https://documentation.commvault.com/11.24/expert/12643_deduplication_faq.html
Why do I see event messages regarding DDB engine resynchronization without running disaster recovery (DR)?
You may see event messages regarding DDB engine resynchronization even without running a disaster recovery operation because the system automatically validates the archive files in a deduplication engine and prunes the orphaned archive files. Backups are allowed to a deduplication engine during the archive file validation. This operation runs every 24 hours or 30 days depending on the number of orphaned archive files.