In the event of a disaster, when the production CommServe host becomes unusable or inaccessible, or if the CommServe host is moved to a new hardware, the latest Disaster Recovery (DR) backups can be used to rebuild the CommServe host.
When a Web Server (where MongoDB database is hosted) becomes unusable or inaccessible, or if the Web Server is moved to a new hardware, the latest DR backups of the MongoDB persistant data can be used to rebuild the MongoDB database.
Before performing a Disaster Recovery (DR) restore, you must verify whether a space reclamation job was performed on any deduplication-enabled cloud storage pool after the DR backup was created.
If a space reclamation job was executed after the DR backup, restoring from that backup can result in data loss.
Example Scenario
To understand the risk, review the following sequence:
- A space reclamation job is run on a deduplication-enabled cloud storage pool. The system marks the Cloud Library Mount Path as Defragmented.
- A DR restore is performed using a backup taken before the space reclamation job. The CommServe database (CSDB) is restored to a prior state, which does not recognize the "Defragmented" status of the mount path.
- When the software performs a pruning operation, the MediaAgent—now aligned with the outdated CSDB—treats the previously defragmented data chunks as non-defragmented. This inconsistency can result in accidental deletion of valid data, causing data loss.
Recommendation
Always check the timeline of space reclamation jobs in relation to your DR backup. If space reclamation occurred after the backup, contact support for guidance before proceeding with the DR restore.
Important
Once restored, the database reflects the state of the production CommCell group when the DR backup was performed. Based on the frequency of the DR backup, you may lose some data such as information about backup operations, entity creation or configuration changes, when you move the CommCell operations to the standby CommServe host.