Manually Recovering the Deduplication Database

You can recover an invalid deduplication database (DDB) by manually reconstructing the DDB. A manual recovery process with the default settings recovers the DDB from the last DDB backup.

If both the DDB and the DDB backup are also detected as invalid, then both the Last DDB Backup Job Id and the Last DDB Backup Time stamp are reset. You must run a full reconstruction of the DDB. The full reconstruction process 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. This process can be time-consuming because the full disk is read during the recovery operation.

Note

  • When running a DDB reconstruction job on a compacted DDB, if the DDB reconstruction job fails, then it will restart from the beginning and not from the point of failure.

  • DDB reconstruction is not supported for combined and archive storage tiers. For more information, see Planning Combined / Archive Storage Tiers.

Before You Begin

  • Ensure that the DDB that has to be reconstructed is in active state.

  • For a multi-partitioned DDB, ensure that the DDB partitions that has to be reconstructed are marked for recovery.

    For more information, see Marking the Deduplication Database for Recovery.

Procedure

  1. From the CommCell Browser, expand Storage Resources > Deduplication Engines > storage_policy_copy.

  2. Right-click the deduplication_database and then click All Tasks > Recover Deduplication Database.

  3. In the Reconstruct Dedupe Database Options dialog box, specify the reconstruction settings:

    • From the Source MediaAgent list, select the MediaAgent that you want to use to read the data on the disk for signature generation during the DDB reconstruction job.

    • If both the DDB and the DDB backup are not available or are detected as invalid, select the Reconstruct entire DDB without using a previous recovery backup check box to perform a full reconstruction of the DDB.

      Note

      If Reconstruct entire DDB without using a previous recovery backup check box is selected, then the DDB reconstruction takes longer than a regular DDB reconstruction job as the DDB is recreated from scratch by reading all jobs associated with the DDB. Using this option can result in any pending deletes being orphaned on the disk library. Therefore it is recommended to run a DDB space reclamation to confirm if there are orphaned chunks to be used.

    • Verify that the Use Scalable Resource Allocation check box is selected as it ensures that if the DDB reconstruction job fails and needs to be restarted, it will restart from the point of failure.

    For more information on recovery options, see Reconstruct Dedupe Database Options.

  4. Click OK.

Result

  • When the reconstruction operation is complete, you can view the reconstruction job history. For more information, see Viewing the Reconstruction Job History for the Deduplication Database.

  • If you had selected the Reconstruct entire DDB without using a previous recovery backup check box, then you can view the following phases in the Job Details dialog box and in Job Controller window:

    • Restore phase - During this phase cleanup of the current DDB location will take place.

    • Add records phase - During this phase the data on the disk library that is associated with the DDB is read to rebuild the DDB location.

    • Prune records phase - During this phase the data in the DDB is cross-verified against the CommServe database.

Loading...