Prerequisites for MongoDB restore and recovery
Ensure that your source MongoDB cluster (during backup) and the target MongoDB cluster (during recovery) have the same:
MongoDB version
Authentication type
Ensure that the user that you configure using the tpconfig command for restoring the MongoDB data has read, write, and execute permissions for all the files and subfolders on the target MongoDB directory. NetBackup uses this user account to recover and run the MongoDB instance.
Before you restore the MongoDB data to an alternate cluster, ensure that you add the alternate MongoDB cluster credentials in the source cluster credentials file.
Ensure that the PEM files or security certificates are available on the destination cluster before you start the recovery operation.
The authentication type of the target cluster during the recovery process must be the same as the authentication type during the backup.
During the recovery process, ensure that the target MongoDB cluster has sufficient free storage space for restoring the data.
During recovery, ensure that you select only one full backup image group and its relevant subsequent incremental images. If you select more than one full backup image group, the recovery may fail as the restored data can get corrupted.
NetBackup for MongoDB plug-in does not support cross-platform file system restore. For example, XFS to ext4 or vice versa is not supported.
During the restore or recovery, ensure that the HostUser value that is defined in the tpconfig command is the same as the host user account that is used to configure the MongoDB cluster (MongoDB daemon's host user account).
Ensure to select a backup host in destination client in the BAR UI before you submit the restore job.
Point-in-time recovery is valid only for recovery from incremental backups.
Canceling a parent job in a compound restore job does not cancel the child restore jobs. You must manually cancel the child restore jobs as well.
After running a restore or a recovery job from the BAR interface, look for the job record and status in the Task Progress tab. The job might take some time to appear in the list and the compound job can take time to trigger the parent pre-recovery check. Click to refresh the task list.
In a Restore Only operation for a sharded cluster, follow the standard Restore Only steps:
Shut down all the MongoDB processes (mongos or mongod) before starting the restore.
The MongoDB log file paths remain the same from the original configuration. If you do an alternate restore:
Make sure that the same path is available during restore
Change the log file path in the configuration file for mongod or mongos process after a successful recovery.
The path to the
.pidfiles must be available on the destination MongoDB cluster to ensure that the recovery operation is successful.In case of a scenario where multiple MongoDB clusters are running on the same server and are backed up using the same or different backup policies, ensure that you select the correct application server that you want to restore.
For example, if there are multiple clusters with the following configuration:
Replica1 Primary: host1:26050 Secondary: host1:26060 Replica2 Primary: host1:26055 Secondary: host1:26066
And you want to recover Replica1, ensure that you specify correct application server and its port (host1-26050) as the source client in the BAR UI.
Before you start a recovery operation, ensure that stale mdbserver (thin client) processes are not running on your MongoDB instance at the following path:
/<mdbserver_location>/<Host>-<MongodPort>-<mdbserver_port in range>/mdbserver
If stale mdbserver processes are running on the MongoDB host for the same MongoDB instance that you want to recover, the recovery operation is unable to shutdown the MongoDB instance. This issue causes the recovery job to stop responding.