Resynchronizing the Deduplication Database
Use Deduplication Database (DDB) Resynchronization to bring the DDB online and revert it to a reusable state from maintenance mode.
About This Task
The DDB is flagged as in maintenance mode when there is an inconsistency between the DDB and the CommServe database. Additionally, when the CommServe Disaster Recovery (DR) Restore process is complete, all eligible active and sealed DDBs are flagged as in maintenance mode. When DDBs are in maintenance mode, pruning will not happen, and backups or Auxiliary Copy jobs cannot access the DDB and go into Waiting state.
Use DDB Resynchronization in the following situations:
- To reconcile inconsistencies between the DDB and the CommServe database. You want to bring the DDB online from maintenance mode.
- To avoid need to seal the DDB after the CommServe DR Restore.
- The DDB sealing can be avoided only if the CommServe DR restore was completed using the DR backup within the past five days.
- For CommServe Disaster Recovery, there are two different ways to start the DDB resynchronization process depending on the situation in which the CommServe DR restore is performed:
- For a planned CommServe restore from a DR backup (for example, CommServe Hardware Refresh), we recommend you to run the DR backup with DDB Activity disabled. See, Shut Down the CommServe Database in the Old Hardware for more information. In this scenario, after DR restore, re-enabling the DDB activity runs the DDB resynchronization process automatically without any user intervention.
- For a unplanned recovery of CommServe or test disaster recovery scenarios, the CommServe restores from a DR backup where the DDB activity is not disabled before the backup. In these scenarios, after DR restore is complete, you need to manually resynchronize the DDBs as described in the below procedure.
How DDB Resynchronization Works
Following is the high-level process for DDB Resynchronization:
- The data in the DDB is validated against the CommServe database to ensure that both the databases are synchronized.
- If the CommServe database and the DDB are not synchronized, the resynchronization process removes the additional data entries in the DDB to reconcile inconsistencies in the CommServe database.
During the DDB resynchronization process, the backup data written to the library between the period of DR backup and the DR restore remains on the disk library, and that data is not recoverable. To prune the data that was written to the library between the period of DR backup and the DR restore, create the SIDBAllowPruneInvalidAfFromDisk additional setting on the MediaAgent before resynchronizing the DDB. For instructions on adding the additional setting, see Add or Modify an Additional Setting.
- When the DDB entries are removed successfully, the DDB is marked online.
- From the CommCell Browser, expand Storage Resources.
- Right-click the Deduplication Engines and then click Synchronize All DDBs.
- In the Synchronize All DDBs dialog box, click Yes.
After you run the DDB resynchronization, verify the status of the DDBs in the Event Viewer window.
To verify the status of the DDBs
- On the ribbon in the CommCell Console, click the Home tab, and then click Event Viewer.
An Event Viewer window is displayed in the CommCell Console.
A description of the synchronization process appears in the Event Viewer as follows:
Result of DDB resynchronization
Resync of Deduplication Engine [ ] success. Store is online now.
Resync of Deduplication Engine [ ] failed. Resync will be attempted again. Please check MediaManager log.
During DDB resynchronization, if the DDB MediaAgent or Index Cache or DDB access path is offline, the resynchronization might fail.
The resynchronization process attempts to run five times, every 15 minutes, on each failed DDB. During this attempts, if the DDB MediaAgent or Index Cache or DDB access path are back online, the resynchronization process will succeed.
Contact your software provider if the resynchronization process exceeds five attempts.
The following event message appear for each DDB that is involved in the DDB Resynchronization.
Result of DDB resynchronization for each DDB
Deduplication Engine [SIDB_SP01_Primary (Mar 25 2014 12:40 AM)] successfully resync-ed and marked online.
Resync of Deduplication Engine [SIDB_SP01_Primary (Mar 25 2014 12:40 AM) ] failed. Resync will be attempted again. Please check MediaManager service log for detailed.
If the resynchronization process of a DDB exceeds maximum (five) attempts, the following message is displayed:
Resync of Deduplication Engine [SIDB_SP01_Primary (Mar 25 2014 12:40 AM) ] cannot proceed. Reason [Maximum resync attempts reached].
Contact your software provider to resolve this issue.
Last modified: 3/1/2018 7:33:05 PM